Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[James Y Knight via lldb-dev]

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 use of git. And
knowing how to use git at at least a basic level is an important skill for
a lot of software development now -- no matter what LLVM does, so I don't
feel bad for making anyone spend time learning how to use it.

I really don't think that promising and requiring that svn-client using
people (especially committers: read-only access seems a lot less
potentially problematic) will keep getting a good development experience
after the migration is a good idea. I mean, if SVN also happens to work
with the chosen hosting/workflow in the end, that's fine, I guess. But, I
feel that should be considered a "if it works, that's okay, but it's not
recommended, and is not guaranteed" kind of thing.

Making that a requirement locks us into the use of github as the primary
repository: no other git hosting has svn support, afaik.
It means we can't introduce any workflows that wouldn't work well for svn
users -- or if we do, that such users will probably complain anew when that
happens.
And if github's svn bridge turns out to have fatal problems, do we then
abandon the migration?



On Wed, Jun 1, 2016 at 2:36 PM, Aaron Ballman via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Wed, Jun 1, 2016 at 2:18 PM, Renato Golin via llvm-dev
>  wrote:
> > On 1 June 2016 at 17:02, John Criswell  wrote:
> >> Do you have a set of volunteers lined up to do such a migration? Getting
> >> people willing to do the migration will obviously be key, and that was
> the
> >> one thing I didn't see in the original email.
> >
> > Hi John,
> >
> > Well, first we need to know if people are in favour, then if the
> > migration won't bring any serious problem, and then we can think of a
> > migration plan. :)
> >
> > So far, it seems people are mostly in favour, with a few that reported
> > being locked into SVN. I had anticipated that, and have proposed
> > GitHub's SVN integration, which allows read-write access, so it should
> > be mostly ok. We need more tests on that side to be sure, though.
> >
> > The biggest problem we're facing right now is how to sync the repos.
> > The existing llvm-repos format with all projects as sub-modules seem
> > to be a good candidate, but I still haven't seen a consensus on how
> > we'd do that.
> >
> > About the migration plan, most people seem to agree a step-by-step
> > process is necessary. So, first we move to git-only, possibly with
> > sub-modules,
>
> Despite people's reservations of a git-only repository? I mean, we
> still don't know that this will even work for people who wish to stay
> with SVN. I am really not comfortable with this decision based on "it
> should be mostly ok" from above, but maybe I am misunderstanding
> something.
>
> ~Aaron
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[James Y Knight via lldb-dev]

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-repository changes (via
assigning a bunch of commits to the same "topic", so they can be reviewed
together).

It also already supports making the submodule commits for the
"llvm-project" superproject. And it is supposed to "soon" support doing an
atomic commit of a "topic" across multiple repositories, which could then
show up as a single change in the "llvm-project" superproject repository. I
don't believe it does that atomically right now, but that's in the plans.

I have found gerrit a really nice code review system in the past for other
projects, and I'm a little afraid that github's PR system will not be
featureful enough by itself. But, maybe it will.

On Thu, Jun 2, 2016 at 2:06 PM, via cfe-dev  wrote:

> Richard Smith via llvm-dev  writes:
>
> > How would you ensure that two dependent changes on different
> > repositories get the same revision number?
> >
> > That is not the case today and isn't (in my opinion) a problem we need
> > to solve with this migration. If there's a small (1-2 revision) window
> > in which things are broken, that's annoying but not a showstopper and
> > not a regression.
>
> With git-subtree you could commit both changes atomically in the "host"
> repository, then split out the histories to the individual components.
>
>  -David
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] GitHub anyone?

[James Y Knight via lldb-dev]

+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 this is that this requires use of cherry-pick,
> > which is not idea.  The way most git repositories work is to put
> > everything that should go into a release branch in the release branch
> > *first* and then merge the release branch to master, ensuring that
> > everything going out in a release will make it into the next release.
> > This is how the gitflow workflow works, for example.
>
> The model of "commit to oldest first" is IMO one of the most stupid
> concepts I have ever seen in git "workflows". It is contrary to the way
> software development works and essentially just a bad workaround for
> broken cherry picks. I've seen more than one project starting to use
> this model due to advocacy after deciding to use git, stumble around
> with it for a release or two and then going back to a normal release
> management approach. Even the argument you have presented here does not
> make sense to me. Just because a change has been committed to a release
> branch, doesn't mean it won't get replaced later.
>
> Joerg
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] Git Move: GitHub+modules proposal

[James Y Knight via lldb-dev]

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 new submodule
pointer, clang will not actually start using the new version of LLVM until
someone gets around to updating the pointer. Meaning, the next time anyone
*ELSE* goes to update the submodule pointer in clang, they would have to,
effectively, integrate all of the as-yet-untested-with-clang changes from
llvm, and fix any problems that might cause. I really don't think we want
that.

What I do think would be nice is a way to associate commits to llvm and
commits to clang as one unit that updates a parent repository. I've
mentioned before that gerrit seems to have that functionality.

I think it'd be a great idea to do some testing, and make a second proposal
centered around using Gerrit to manage commits to the github repository,
versus committing to github directly. I'm not sure if I'll have time to do
that properly, though.


On Mon, Jun 27, 2016 at 10:39 AM, Rafael Espíndola 
wrote:

> >> As for updating the meta repository: We could disable write access for
> the normal llvm developer and delegate the submodule bumping to an external
> >> server. I believe this would be an easy enough job for buildbot or
> jenkins.
> >
> > The plan is to disable all write access to this repository (otherwise
> > we'll create a nightmare). Having an external counter could be
> > problematic due to synchronisation issues.
> >
> > If the hook doesn't work, we'll have serious problems.
>
> So, I probably missed something, but what was the main objection to
> just using submodules? This would put llvm inside clang instead of the
> other way around. When changing an API one currently has to
>
> * Change llvm.
> * Quickly change clang and hope no bot picks up a revision with only
> the llvm change.
>
> With submodules it becomes
>
> * Change llvm.
> * Change clang and in the same atomic commit change what revision the
> submodule points to.
>
>
> Cheers,
> Rafael
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Git Move: GitHub+modules proposal

[James Y Knight via lldb-dev]

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 keep llvm and clang in lock step we should probably
> probably
> > just have them in the same repository like
> > https://github.com/llvm-project/llvm-project.
>
> That is similar to the proposal we have, except that llvm-projects
> will have sub-modules.
>
> Having all of them in the same physical repository is a big problems
> for those that only use a small subset of the components, which is the
> vast majority of users, most of the time (all buildbots, Jenkins,
> local development, downstream users, even releases don't clone all
> repos).


(This is kinda a sidenote, because it doesn't actually change the
problem-space at all, but :)

I really disagree that it'd cause big problems to merge them all.
Especially when using git, which makes it a lot easier to keep a local
shared copy of the repository, so you don't need to re-download the whole
world every time you want a clean checkout. The entire set of llvm code,
all put together, is really just not that big in the end. But I do find it
annoying to have the many different repositories to track, and I don't
really see the value of having as many as we do.

However, even without big problems, it does make some sense to keep the
C/C++ language separate from the (mostly-)language-independent llvm
backend. There are a multitude of other frontends which use LLVM too: go,
swift, rust, etc. Would we really want to pull in all of those into a
single repo, as well, if they happened to get contributed to the llvm
project organization? Probably not.

So, while this wouldn't affect the need for a "llvm-project" repository, it
might be nice to consider merging some of the other ones together

E.g.:
llvm: Core language-independent functionality: LLVM, assembler, and linker
tools. (merge in lld, and maybe compiler-rt, to the llvm repository).
clang: C/C++ frontend and related libraries (merge in clang-tools-extra,
libcxx, and libcxxabi into the clang repository).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Sequential ID Git hook

[James Y Knight via lldb-dev]

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 is the first I've heard of
that as a thing that needs to be done.

There was a previous discussion about putting an sequential ID in the
"llvm-project" repo commit messages (although, even that I'd say is
unnecessary), but not anywhere else.



On Thu, Jun 30, 2016 at 7:42 AM, Renato Golin via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Now that we seem to be converging to an acceptable Git model, there
> was only one remaining doubt, and that's how the trigger to update a
> sequential ID will work. I've been in contact with GitHub folks, and
> this is in line with their suggestions...
>
> Given the nature of our project's repository structure, triggers in
> each repository can't just update their own sequential ID (like
> Gerrit) because we want a sequence in order for the whole project, not
> just each component. But it's clear to me that we have to do something
> similar to Gerrit, as this has been proven to work on a larger
> infrastructure.
>
> Adding an incremental "Change-ID" to the commit message should
> suffice, in the same way we have for SVN revisions now, if we can
> guarantee that:
>
>  1. The ID will be unique across *all* projects
>  2. Earlier pushes will get lower IDs than later ones
>
> Other things are not important:
>
>  3. We don't need the ID space to be complete (ie, we can jump from
> 123 to 125 if some error happens)
>  4. We don't need an ID for every "commit", but for every push. A
> multi-commit push is a single feature, and doing so will help
> buildbots build the whole set as one change. Reverts should also be
> done in one go.
>
> What's left for the near future:
>
>  5. We don't yet handle multi-repository patch-sets. A way to
> implement this is via manual Change-ID manipulation (explained below).
> Not hard, but not a priority.
>
>
>   Design decisions
>
> This could be a pre/post-commit trigger on each repository that
> receives an ID from somewhere (TBD) and updates the commit message.
> When the umbrella project synchronises, it'll already have the
> sequential number in. In this case, the umbrella project is not
> necessary for anything other than bisect, buildbots and releases.
>
> I personally believe that having the trigger in the umbrella project
> will be harder to implement and more error prone.
>
> The server has to have some kind of locking mechanism. Web services
> normally spawn dozens of "listeners", meaning multiple pushes won't
> fail to get a response, since the lock will be further down, after the
> web server.
>
> Therefore, the lock for the unique increment ID has to be elsewhere.
> The easiest thing I can think of is a SQL database with auto-increment
> ID. Example:
>
> Initially:
> sql> create table LLVM_ID ( id int not null primary key
> auto_increment, repository varchar not null, hash varchar nut null );
> sql> alter table LLVM_ID auto_increment = 30;
>
> On every request:
> sql> insert into LLVM_ID values ("$repo_name", "$hash");
> sql> select_last_inset_id(); -> return
>
> and then print the "last insert id" back to the user in the body of
> the page, so the hook can update the Change-id on the commit message.
> The repo/hash info is more for logging, debugging and conflict
> resolution purposes.
>
> We also must limit the web server to only accept connections from
> GitHub's servers, to avoid abuse. Other repos in GitHub could still
> abuse, and we can go further if it becomes a problem, but given point
> (3) above, we may fix that only if it does happen.
>
> This solution doesn't scale to multiple servers, nor helps BPC
> planning. Given the size of our needs, it not relevant.
>
>
>   Problems
>
> If the server goes down, given point (3), we may not be able to
> reproduce locally the same sequence as the server would. Meaning
> SVN-based bisects and releases would not be possible during down
> times. But Git bisect and everything else would.
>
> Furthermore, even if a local script can't reproduce exactly what the
> server would do, it still can make it linear for bisect purposes,
> fixing the local problem. I can't see a situation in which we need the
> sequence for any other purpose.
>
> Upstream and downstream releases can easily wait a day or two in the
> unlucky situation that the server goes down in the exact time the
> release will be branched.
>
> Migrations and backups also work well, and if we use some cloud
> server, we can easily take snapshots every week or so, migrate images
> across the world, etc. We don't need duplication, read-only scaling,
> multi-master, etc., since only the web service will be writing/reading
> from it.
>
> All in all, a "robust enough" solution for our needs.
>
>
>   Bundle commits
>
> Just FYI, here's a 

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[James Y Knight via lldb-dev]

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 url, and no longer recreate it even if we find a
minor deficiency.

This will allow people to start converting their internal processes to use
it and depend on hashes safely. So, if you or anyone else wants to suggest
changes, now's the best time.


On Mon, Oct 22, 2018 at 5:16 PM NAKAMURA Takumi 
wrote:

> James and Tom,
>
> One question. Would the monorepo be fixed and would it not be re-created
> after the day?
>
> I am deeply cosmetic-checking the repo. For now, I haven't found critical
> issues, though.
>
> Takumi
>
> On Sat, Oct 20, 2018 at 9:47 AM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> TLDR: Official monorepo repository will be published on
>> Tuesday, Oct 23, 2018.  After this date, you should modify
>> your workflows to use the monorepo ASAP.  Current workflows
>> will be supported for at most 1 more year.
>>
>> Hi,
>>
>> We had 2 round-tables this week at the Developer Meeting to
>> discuss the SVN to GitHub migration, and I wanted to update
>> the rest of the community on what we discussed.
>>
>> The most important outcome from that meeting is that we
>> now have a timeline for completing the transition which looks
>> like this:
>>
>> Tues Oct 23, 2018:
>>
>> The latest monorepo prototype[1] will be moved over to the LLVM
>> organization github project[2] and will begin mirroring the current
>> SVN repository.  Commits will still be made to the SVN repository
>> just as they are today.
>>
>> All community members should begin migrating their workflows that
>> rely on SVN or the current git mirrors to use the new monorepo.
>>
>> For CI jobs or internal mirrors pulling from SVN or
>> http://llvm.org/git/*.git you should modify them to pull from
>> the new monorepo and also to deal with the new repository
>> layout.
>>
>> For Developers, you should begin using the new monorepo
>> for your development and using the provided scripts[3]
>> to commit your code.  These scripts will allow to commit
>> to SVN from the monorepo without using git-svn
>>
>>
>>
>>
>>
>>
>> [1] https://github.com/llvm-git-prototype/llvm
>> [2] https://github.com/llvm/
>> [3]
>> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
>>
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Updates on SVN to GitHub migration

[James Y Knight via lldb-dev]

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 maybe it just starts
working after we do so.

On Thu, Nov 8, 2018 at 3:53 PM Anton Korobeynikov 
wrote:

> Some status update wrt GitHub SVN bridge.
>
> It does not work for any non-trivial (= LLVM) repo. I filled the issue
> there, however, there is no ETA when it will be fixed. Even worse,
> there are no promises that the issue will be addressed at all. Though
> they are aware that this is the issue for us.
> On Thu, Nov 8, 2018 at 12:53 PM Nico Weber via llvm-dev
>  wrote:
> >
> > What's the status here?
> >
> > Can someone keep https://llvm.org/docs/Proposals/GitHubMove.html
> updated with the current status of things?
> >
> > And once things are usable, probably update
> https://llvm.org/docs/GettingStarted.html#for-developers-to-work-with-a-git-monorepo
> as well.
> >
> > On Wed, Oct 24, 2018 at 4:57 AM Jacob Carlborg via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >>
> >> On 2018-10-24 08:25, Whisperity via cfe-dev wrote:
> >> > They are not shown in the project graph, but if you open the "branch"
> >> > drop down it has a tab named 'Tags'.
> >>
> >> It shows some tags there, but not all of them. But clicking "releases"
> >> then "Tags" will show this page [1], which seems to include all of them.
> >>
> >> [1] https://github.com/llvm-git-prototype/llvm/tags
> >>
> >> --
> >> /Jacob Carlborg
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> > ___
> > LLVM Developers mailing list
> > llvm-...@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM git monorepo mirror published

[James Y Knight via lldb-dev]

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 is currently being triggered via cron every minute on a
redundant pair of llvm project AWS instances. You should currently expect
the round-trip latency from an svn commit to it showing up in git to be
somewhere around 20-90 seconds. (I'd like to reduce that latency, but it
hasn't been the priority yet).

The updated workflow docs, and instructions on migrating in-progress work
have not yet been finalized, but will come soon.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[James Y Knight via lldb-dev]

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 possible to such users.

On Tue, Mar 19, 2019 at 3:15 PM Roman Lebedev via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Tue, Mar 19, 2019 at 10:00 PM Tom Stellard via cfe-dev
>  wrote:
> >
> > Hi,
> >
> > I would like to follow up on the previous thread[1], where there was a
> consensus
> > to disallow merge commits in the llvm github repository, and start a
> discussion
> > about how we should enforce this policy.
> >
> > Unfortunately, GitHub does not provide a convenient way to fully enforce
> this policy.
> > We can enforce it for pull requests, but not for direct pushes to the
> master branch,
> > so we will have to come up with our own solution if we want to
> completely prevent
> > merge commits.  I've spent some time looking into this and here are a few
> > options that I've come up with (If you are a GitHub expert and have other
> > suggestions, please let us know):
> >
> > 1. Have either a status check or use the "Rebase and Merge" policy for
> pull requests
> > to disallow merge commits.  Disable direct pushes to the master branch
> and update the
> > git-llvm script to create a pull request when a developer does `git llvm
> push` and
> > then have it automatically merged if there are no merge commits.
> >
> > 2. Enforce no merge commits for pull requests, but sill allow developers
> to push directly
> > to master without checking for merge requests.  This is essentially a
> best effort
> > approach where we avoid having to implement our own custom work-flow for
> committing,
> > while accepting the possibility that someone might accidentally push a
> merge commit.
> >
> > 3. Disable direct pushes to master, don't update the git-llvm script and
> require all
> > developers to use pull requests, where this policy will be enforced.
> >
> > Which option do you prefer?
> All these options include at least partial usage of/switch to github pr's.
> I don't think that was discussed before. (FWIW i'm opposed to that.)
>
> Is there a fourth option - ask github whether they could make an exception
> for LLVM to use server-side hooks? They are available in github enterprise.
>
> > -Tom
> Roman.
>
> > [1] http://lists.llvm.org/pipermail/llvm-dev/2019-January/129723.html
> > ___
> > cfe-dev mailing list
> > cfe-...@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[James Y Knight via lldb-dev]

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
> welcoming as possible to such users.
> Still we'd need some policy & checks here. Say, what if someone will
> issue a PR to LLVM 4.0 branch? With clear code style violations, etc.
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Reminder: SVN will be retired on Oct 21, 2019 -- Please migrate your workflows to github ASAP.

[James Y Knight via lldb-dev]

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, as of
https://github.com/llvm/llvm-project/commit/541faedd6675d8e312cb11b045d2f802e289d610


> It is slightly infuriating that most of the documentation as to how to use
> the SVN repositories has vanished (which is still relevant to contributing
> to test-suite and lnt), and it seems there is little guidance about what
> these repos will do when the monorepo moves to git and GitHub.
>

The plan is for these repos to live on github as well, the same way they
are laid out currently in the github project. E.g. test-suite lives in
https://github.com/llvm/llvm-test-suite).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub Migration Schedule and Plans

[James Y Knight via lldb-dev]

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 Stellard > > wrote:
>> >
>> > On 10/09/2019 11:05 PM, Mehdi AMINI wrote:
>> > >
>> > >
>> > > On Wed, Oct 9, 2019 at 10:16 PM Tom Stellard via cfe-dev <
>> cfe-...@lists.llvm.org  > cfe-...@lists.llvm.org >> wrote:
>> > >
>> > > Hi,
>> > >
>> > > We're less than 2 weeks away from the developer meeting, so I
>> wanted to
>> > > give an update on the GitHub migration and what's (hopefully)
>> going to
>> > > happen during the developer meeting.
>> > >
>> > > Everyone who has added their information to the
>> github-usernames.txt
>> > > file in SVN before today should have received an invite to
>> become a collaborator
>> > > on the llvm-project repository.  If you did not receive an
>> invite and think
>> > > you should have, please contact me off-list.  I will continue
>> to monitor the
>> > > file for new updates and periodically send out new batches of
>> invites.
>> > >
>> > > There is still some ongoing work to get the buildbots ready
>> and the mailing lists
>> > > ready, but we are optimistic that the work will be done in
>> time.
>> > >
>> > > The team at GitHub has finished implementing the "Require
>> Linear History"
>> > > branch protection that we requested.  The feature is in beta
>> and currently
>> > > enabled in the llvm-project repository.  This means that we
>> will have the
>> > > option to commit directly via git, in addition to using the
>> git-llvm script.
>> > > A patch that updates git-llvm to push to git instead of svn
>> can be found here:
>> > > https://reviews.llvm.org/D67772.  You should be able to test
>> it out on your
>> > > own fork of the llvm-project repository.
>> > >
>> > > The current plan is to begin the final migration steps on the
>> evening (PDT)
>> > > of October 21.  Here is what will happen:
>> > >
>> > > 1. Make SVN read-only.
>> > > 2. Turn-off the SVN->git update process.
>> > > 3. Commit the new git-llvm script directly to github.
>> > > 4. Grant all contributors write access to the repository.
>> > >
>> > >
>> > > Is the repo configured to forbid contributors to create new
>> branches? I'm worried about the "jungle" it can become quickly if we leave
>> open the possibility to create branches "at will" in the repo, I rather
>> leave this to maintainers.
>> > >
>> >
>> > I haven't been able to find a way to restrict branch creation for
>> committers,
>> > I'm not sure if this is even possible.
>> >
>> >
>> > I think you can just go to the branch settings, add a new branch
>> protection rule, match on everything but master, and check "Restrict who
>> can push to matching branches".
>> >
>>
>> I tried this, and the branch protections only come into effect after a
>> branch
>> has been creating, so this doesn't prevent new branches.  It's actually
>> worse
>> than doing nothing, because once the branch is created the branch
>> protection
>> prevents you from deleting it.
>>
>> -Tom
>>
>
> FWIW, we're interested in periodically (weekly) tagging well-tested/stable
> revisions, but via a branch instead of just a tag so we can include which
> cherrypicks (e.g. reverts or fixes) are needed. We do this with the current
> svn repo so we'd just be porting existing functionality to github.
>
> (Also, I'm not sure this announcement thread with all the *-dev lists is
> the best place to discuss branching policy, but I wanted to get this bit in
> since y'all brought it up :) )
>

IMO -- we should generally discourage random developer branches, and
instead encourage people to fork the repo and do their work there. But I'd
concur that it's not so big a concern as to require it to be prohibited via
tooling, since they're easily removable. I can imagine some cases where a
temporary dev branch in the main repo might be appropriate to use, and it'd
be nice not to prohibit such a valid use.

With regards to these sorts of "vendor release branches", though -- I'm
strongly against putting those in the main repo. That usage would certainly
be best handled with a separate Google "fork" of the llvm-project
repository -- and similarly for anyone else who wants to do it. Putting
such branches into the main llvm repo means that everyone pulling it pulls
down all the google release branches by default, which is really
unnecessary clutter (check out
https://github.com/llvm/llvm-project-legacy-branches if you'd like to see
what such clutter starts to look li

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues

[James Y Knight via lldb-dev]

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 Mon, Mar 16, 2020 at 11:41 AM James Henderson via cfe-dev <
cfe-...@lists.llvm.org> wrote:

>
>
> On Mon, 16 Mar 2020 at 15:08, Tom Stellard  wrote:
>
>> On 03/16/2020 08:00 AM, James Henderson wrote:
>> >
>> >
>> > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <
>> cfe-...@lists.llvm.org > wrote:
>> >
>> > On 02/10/2020 07:40 PM, Tom Stellard wrote:
>> > > On 01/30/2020 12:47 PM, David Major wrote:
>> > >> Would it make sense to wait until 10.0.0 is released, in order
>> to keep all the blockers in one place?
>> > >>
>> > >
>> > > Yes, I think this makes sense, let's postpone until then.
>> > >
>> >
>> > Hi,
>> >
>> > 10.0.0-rc4 was just released, and I think we are at the point in
>> the release cycle
>> > where it is safe to begin the migration to GitHub issues.
>> >
>> > I would like to propose doing the migration in one week (March
>> 23).  This means
>> > making the existing bugzilla read-only, and updating the
>> documentation to tell users
>> > to file issues at GitHub.
>> >
>> >
>> > Don't forget to update the URL used in crash messages to point at the
>> right location.
>> >
>> >
>> > We are still trying to figure out the best way to import bugs
>> > from bugzilla into GitHub, so this step will be done at a later
>> date.
>> >
>> >
>> > Making bugzilla read-only seems like a bad idea until all existing
>> issues have been migrated. What if people need to update an existing bug
>> once the migration to using Github issues has happened before importing has
>> also happened?
>> >
>>
>> This was a mistake on my part.  The plan is to disable creation of new
>> bugs in bugzilla and not
>> to make it read-only.  If you look at the original RFC, it says GitHub
>> issues
>> would be used for new issues, and existing issues will continue to be
>> updated in bugzilla,
>> and this is what I'm proposing.
>>
>> >
>> >
>> > For the initial list of tags, I propose we generate the list based
>> on the most commonly
>> > used categories in bugzilla.  This should be enough to get us
>> started and we can always
>> > add more tags as we go.
>> >
>> >
>> > I'd like this list to be fleshed out before migration is agreed. I'm
>> concerned different people will have wildly different ideas of what
>> "commonly used" might mean, which could in turn have an impact on the
>> viability of this tag list.
>> >
>>
>> Most commonly used here means categories with the most bugs.  So, this
>> would be
>> based on raw bug counts and not just someone's opinion.
>>
>> -Tom
>>
>
> That's what I thought might be the case, and where I take issue with it.
> I've said this on several previous occasions - I think it makes sense for
> tags/bugzilla components etc. to exist for each individual executable, as
> well as the various libraries. Let's say I'm a user of a tool like
> llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't
> know where to file it (and no, I don't think a catch-all "binutils" tag is
> useful - not every developer will know what counts as a "binutils" tag). At
> the time of writing there are exactly three bugs for llvm-size. That
> presumably isn't going to meet any threshold imposed, so this tag wouldn't
> be created, and I wouldn't know where to file my bug, so I probably would
> either guess (and quite likely get it wrong), or not add a tag, which means
> that developers who are focused on developing the binutils (and would
> therefore have subscribed to this tag) won't see the issue. I might even
> not file the bug at all.
>
>
>> >
>> >
>> > I've also implemented a notification system using GitHub actions
>> that will make
>> > it possible to subscribe to individual issue tags, so we would
>> enable this on Monday
>> > as well.
>> >
>> > What does everyone think?
>> >
>> > Thanks,
>> > Tom
>> >
>> >
>> > > -Tom
>> > >
>> > >>
>> > >>
>> > >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
>> llvm-...@lists.llvm.org  > llvm-...@lists.llvm.org >> wrote:
>> > >>
>> > >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> > >> > mailto:cfe-...@lists.llvm.org>
>> >> wrote:
>> > >> >>
>> > >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
>> > >> >>> We held a round-table at the llvm dev conference about
>> what other pieces of Github infrastructure we may want to use. This thread
>> i

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[James Y Knight via lldb-dev]

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.
2. The numbering can be fully-controlled.
Once the bugs are migrated to *some* github repository, individual issues
can then be "moved" between repositories, and github will redirect from the
movefrom-repository's bug to the target repository's bug.

We could also just have llvm.org/PR### be the url only for legacy bugzilla
issue numbers -- and have it use a file listing the mappings of bugzilla id
-> github id to generate the redirects. (GCC just did this recently for svn
revision number redirections,
https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).

Then we could introduce a new naming scheme for github issue shortlinks.

On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
>> Hi,
>>
>> I wanted to continue discussing the plan to migrate from Bugzilla to
>> Github.
>> It was suggested that I start a new thread and give a summary of the
>> proposal
>> and what has changed since it was originally proposed in October.
>>
>> == Here is the original proposal:
>>
>> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>>
>> == What has changed:
>>
>> * You will be able to subscribe to notifications for a specific issue
>>   labels.  We have a proof of concept notification system using github
>> actions
>>   that will be used for this.
>>
>> * Emails will be sent to llvm-bugs when issues are opened or closed.
>>
>> * We have the initial list of labels:
>> https://github.com/llvm/llvm-project/labels
>>
>> == Remaining issue:
>>
>> * There is one remaining issue that I don't feel we have consensus on,
>> and that is what to do with bugs in the existing bugzilla.  Here are some
>> options
>> that we have discussed:
>>
>> 1. Switch to GitHub issues for new bugs only.  Bugs filed in bugzilla
>> that are
>> still active will be updated there until they are closed.  This means
>> that over
>> time the number of active bugs in bugzilla will slowly decrease as bugs
>> are closed
>> out.  Then at some point in the future, all of the bugs from bugzilla
>> will be archived
>> into their own GitHub repository that is separate from the llvm-project
>> repo.
>>
>> 2. Same as 1, but also create a migration script that would allow anyone
>> to
>> manually migrate an active bug from bugzilla to a GitHub issue in the
>> llvm-project
>> repo.  The intention with this script is that it would be used to migrate
>> high-traffic
>> or important bugs from bugzilla to GitHub to help increase the visibility
>> of the bug.
>> This would not be used for mass migration of all the bugs.
>>
>> 3. Do a mass bug migration from bugzilla to GitHub and enable GitHub
>> issues at the same time.
>> Closed or inactive bugs would be archived into their own GitHub
>> repository, and active bugs
>> would be migrated to the llvm-project repo.
>>
>
> Can we preserve the existing bug numbers if we migrate this way? There are
> lots of references to "PRx" in checked in LLVM artifacts and elsewhere
> in the world, as well as links to llvm.org/PRx, and if we can
> preserve all the issue numbers this would ease the transition pain
> substantially.
>
>
>> The key difference between proposal 1,2 and 3, is when bugs will be
>> archived from bugzilla
>> to GitHub.  Delaying the archiving of bugs (proposals 1 and 2) means that
>> we can migrate
>> to GitHub issues sooner (within 1-2 weeks), whereas trying to archive
>> bugs during the
>> transition (proposal 3) will delay the transition for a while (likely
>> several months)
>> while we evaluate the various solutions for moving bugs from bugzilla to
>> GitHub.
>>
>>
>> The original proposal was to do 1 or 2, however there were some concerns
>> raised on the list
>> that having 2 different places to search for bugs for some period of time
>> would
>> be very inconvenient.  So, I would like to restart this discussion and
>> hopefully we can
>> come to some kind of conclusion about the best way forward.
>>
>> Thanks,
>> Tom
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[James Y Knight via lldb-dev]

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/writing-on-github/autolinked-references-and-urls
)

On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev <
cfe-...@lists.llvm.org> wrote:

>
> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >>
> >>  +1 to James's take
> >>
> >>  I'd prefer simplicity of implementation over perfection here.
> >>
> >> If we end up with two different bug numbering systems, that's a problem
> that we will be paying for for many years. It's worth some investment now
> to avoid that problem. And it doesn't seem like it really requires much
> investment.
> >>
> >> Here's another path we could take:
> >>
> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror the
> bugzilla issues there. Iterate until we're happy, as per James's proposal.
> >> 2) Sync the forked repository to the llvm repository, delete the llvm
> repository, rename "bugs" to "llvm", and make it public.
> >>
> >> Then we'll have the first N bugs in llvm-project/llvm being *exactly*
> the bugzilla bugs, and we'll have excised the existing github issues that
> we want to pretend never existed anyway.
> >>
> >>
> >> I think we've missed an important step in the planning here: we've not
> agreed on a set of goals for the transition. Here are mine:
> >>
> >>   * We end up with one single issue tracking system containing all
> issues, both old and new, both open and closed.
> >>   * All links and references to existing bugs still work.
> >>   * We have a single bug numbering system covering all bugs, and old
> bugs retain their numbers.
> > Why are the bug numbers important?  Could you help give some example use
> cases that require having
> > a non-intersecting set of bug numbers for bugzilla bugs and github
> issues?
>
>
> While I have no experience in bugzilla or github tooling, the two step
> process described by Richard doesn't seem to be very complicated.
>
>
> As mentioned by others, we have commits and tests (and sometimes source
> files) that explicitly mention bug numbers. I do regularly look up bugs
> from a decade ago to determine if a test or some code still has
> relevance or not. If PR3214 can be one of two bugs, it does not only
> increase lookup time but also add confusion to everyone involved.
>
>
> Cheers,
>
>Johannes
>
>
>
> > -Tom
> >
> >
> >> It sounds like we don't all agree that the last point is important, but
> if we can achieve it without any significant additional cost, why not do so?
> >>
> >>  Philip
> >>
> >>  On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >>>  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.
> >>>  2. The numbering can be fully-controlled.
> >>>  Once the bugs are migrated to /some/ github repository,
> individual issues can then be "moved" between repositories, and github will
> redirect from the movefrom-repository's bug to the target repository's bug.
> >>>
> >>>  We could also just have llvm.org/PR###
>   be the url only
> for legacy bugzilla issue numbers -- and have it use a file listing the
> mappings of bugzilla id -> github id to generate the redirects. (GCC just
> did this recently for svn revision number redirections,
> https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
> >>>
> >>>  Then we could introduce a new naming scheme for github issue
> shortlinks.
> >>>
> >>>  On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <
> llvm-...@lists.llvm.org > wrote:
> >>>
> >>>  On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org > wrote:
> >>>
> >>>  Hi,
> >>>
> >>>  I wanted to continue discussing the plan to migrate from
> Bugzilla to Github.
> >>>  It was suggested that I start a new thread and give a
> summary of the proposal
> >>>  and what has changed since it was originally proposed in
> October.
> >>>
> >>>  == Here is the original proposal:
> >>>
> >>>
> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
> >>>
> >>>  == What has changed:
> >>>
> >>>  * You will be able to subscribe to notifications for a
> specific iss

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[James Y Knight via lldb-dev]

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.

On Wed, Apr 22, 2020 at 8:32 AM Anton Korobeynikov 
wrote:

> GitHub also supports custom prefixes for the issues. However, here is
> another limitation: the prefix must be at least 3 letters, so we
> cannot, for example, autolink PR1234 issues. Already asked whether
> this restriction could be lifted.
>
> On Wed, Apr 22, 2020 at 3:15 PM James Y Knight via llvm-dev
>  wrote:
> >
> > 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/writing-on-github/autolinked-references-and-urls
> )
> >
> > On Tue, Apr 21, 2020, 10:43 PM Johannes Doerfert via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
> >>
> >>
> >> On 4/21/20 7:00 PM, Tom Stellard via llvm-dev wrote:
> >> > On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> >> >> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev <
> cfe-...@lists.llvm.org > wrote:
> >> >>
> >> >>  +1 to James's take
> >> >>
> >> >>  I'd prefer simplicity of implementation over perfection here.
> >> >>
> >> >> If we end up with two different bug numbering systems, that's a
> problem that we will be paying for for many years. It's worth some
> investment now to avoid that problem. And it doesn't seem like it really
> requires much investment.
> >> >>
> >> >> Here's another path we could take:
> >> >>
> >> >> 1) Fork the llvm repository to a private "bugs" repository. Mirror
> the bugzilla issues there. Iterate until we're happy, as per James's
> proposal.
> >> >> 2) Sync the forked repository to the llvm repository, delete the
> llvm repository, rename "bugs" to "llvm", and make it public.
> >> >>
> >> >> Then we'll have the first N bugs in llvm-project/llvm being
> *exactly* the bugzilla bugs, and we'll have excised the existing github
> issues that we want to pretend never existed anyway.
> >> >>
> >> >>
> >> >> I think we've missed an important step in the planning here: we've
> not agreed on a set of goals for the transition. Here are mine:
> >> >>
> >> >>   * We end up with one single issue tracking system containing all
> issues, both old and new, both open and closed.
> >> >>   * All links and references to existing bugs still work.
> >> >>   * We have a single bug numbering system covering all bugs, and old
> bugs retain their numbers.
> >> > Why are the bug numbers important?  Could you help give some example
> use cases that require having
> >> > a non-intersecting set of bug numbers for bugzilla bugs and github
> issues?
> >>
> >>
> >> While I have no experience in bugzilla or github tooling, the two step
> >> process described by Richard doesn't seem to be very complicated.
> >>
> >>
> >> As mentioned by others, we have commits and tests (and sometimes source
> >> files) that explicitly mention bug numbers. I do regularly look up bugs
> >> from a decade ago to determine if a test or some code still has
> >> relevance or not. If PR3214 can be one of two bugs, it does not only
> >> increase lookup time but also add confusion to everyone involved.
> >>
> >>
> >> Cheers,
> >>
> >>Johannes
> >>
> >>
> >>
> >> > -Tom
> >> >
> >> >
> >> >> It sounds like we don't all agree that the last point is important,
> but if we can achieve it without any significant additional cost, why not
> do so?
> >> >>
> >> >>  Philip
> >> >>
> >> >>  On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
> >> >>>  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.
> >> >>>  2. The numbering can be fully-controlled.
> >> >>>  Once the bugs are migrated to /some/ github repository,
> individual issues can then be "moved" between repositories, and github will
> redirect from the movefrom-repository's bug to the target repository's bug.
> >> >>>
> >> >>>  We could also just have llvm.org/PR###
>   be the url only
> for legacy bugzilla issue numbers -- and have it use a file listing the
> mappings of bugzilla id -> github id to generate the redirects. (GCC just
> did this recently for svn revision number redirections,
> https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
> >> >>>
> >> >>>  Then we could introduce a new naming scheme for github issue
> 

Re: [lldb-dev] [cfe-dev] Mailing List Status Update

[James Y Knight via lldb-dev]

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
discourse instance. Which definitely isn't what I want at all. I don't want
to subscribe to MLIR, for example.

In general, I'd say I'm pretty uncomfortable with switching from a mailing
list to discourse. Discourse seems entirely reasonable to use for
end-user-facing forums, but I'm rather unconvinced about its suitability as
a dev-list replacement. Other communities (e.g. python) seem to have a
split, still: mailing lists for dev-lists, and discourse for
end-user-facing forums.

I'd also note that Mailman3 provides a lot more features than what we're
used to with mailman2, including the ability to interact/post through the
website.

Maybe someone can convince me that I'm just being a curmudgeon, but at this
point, I'd say we ought to be investigating options to have Someone Else
manage the mailman service, and keep using mailing lists, rather than
attempting to switch to discourse.


On Tue, Jun 1, 2021 at 4:50 PM Tom Stellard via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hi,
>
> We recently[1] ran into some issues with the mailing lists that caused
> us to disable automatic approval of subscriptions.  Over the past few
> months, the LLVM Foundation Board of Directors have been investigating
> solutions to this issue and are recommending that the project move its
> discussion forum from mailman to Discourse[2].
>
> The proposed migration plan is to move the discussion lists (e.g *-dev,
> *-users lists) to Discourse as soon as possible.  The commit email lists
> (*-commits lists) will remain on mailman until a not-yet-determined date
> in the future, after which they will be replaced by something else.
> Some commit lists alternatives include Discourse and GitHub commit
> comments (but there may be others).
>
> Here are the reasons why the LLVM Foundation Board of Directors is
> recommending this change:
>
> - The LLVM project discussion lists cannot be adequately maintained by our
>current volunteer infrastructure staff and without changes we run the
>risk of a major outage.
>
> - We are able to make this change without significant impact to user's or
>developer's daily workflows because Discourse supports email
> subscriptions
>and posting (NOTE: if you are concerned that your workflow may be
> impacted
>by this change, please contact the Infrastructure Working Group[3], so
>they can help test your workflow with Discourse.)
>
> - Discourse gives us additional features that will benefit the community:
>- Easy to signup and subscribe to categories
>- Better moderation tools.
>- Web-based user interface.
>- Ability to send announcements to multiple categories to avoid having
> to
>  cross-post community wide announcements.
>
> - A subset of the community (MLIR) have been experimenting with Discourse
>for over a year and are able to provide feedback about this experience
>to the Board of Directors.
>
> We did also consider one alternative, which was migrating our lists to a
> mailman hosting service.  However, we concluded that with all the work it
> would take to migrate our lists to another service, it would be better
> if we moved to a service (like Discourse) that provided more features
> than what we have now.
>
> We understand that moving to Discourse is a change for the community and
> that people may be worried about this having a negative impact on their
> participation in the project.  As mentioned above, we believe that this
> change can be done without significant impact to anyone’s workflows.
> If you disagree, please contact the Infrastructure Working Group, to
> document the impact to your workflow, so we can work together to find
> a solution for your issue.
>
> If you have any other questions or comments you can raise them on this
> thread and please keep criticisms constructive and on topic.
>
>
> LLVM Foundation Board of Directors
>
> [1] https://lists.llvm.org/pipermail/llvm-dev/2021-March/149027.html
> [2] https://www.discourse.org/
> [3] https://github.com/llvm/llvm-iwg
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

[James Y Knight via lldb-dev]

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 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
>> discourse instance. Which definitely isn't what I want at all. I don't want
>> to subscribe to MLIR, for example.
>>
>> In general, I'd say I'm pretty uncomfortable with switching from a
>> mailing list to discourse. Discourse seems entirely reasonable to use for
>> end-user-facing forums, but I'm rather unconvinced about its suitability as
>> a dev-list replacement.
>>
>
> Can you elaborate why or what aspect makes it unsuitable? We've been using
> this exclusively without a  "dev list" for MLIR and it is working perfectly
> well as far as I can tell. I believe Swift does the same thing as well.
>

My first concern is that it does not appear to be actually usable via email
in the same way the existing collection of mailing lists is. I wonder
if these others primarily interact with it through the website, rather than
via email? It certainly seems like a reasonable web forum, even if not a
reasonable mailing list service.

I have not used discourse enough to really have a firm opinion on whether
(or why) it would be a bad idea to switch from an email workflow to a
webforum workflow using the discourse website. Possibly that could be OK
(although, at this point, unconvinced), but it *would* be a major change in
workflow, and is not what the original pitch was.


Thanks,
>
> --
> Mehdi
>
>
>
>> Other communities (e.g. python) seem to have a split, still: mailing
>> lists for dev-lists, and discourse for end-user-facing forums.
>>
>> I'd also note that Mailman3 provides a lot more features than what we're
>> used to with mailman2, including the ability to interact/post through the
>> website.
>>
>> Maybe someone can convince me that I'm just being a curmudgeon, but at
>> this point, I'd say we ought to be investigating options to have Someone
>> Else manage the mailman service, and keep using mailing lists, rather than
>> attempting to switch to discourse.
>>
>>
>> On Tue, Jun 1, 2021 at 4:50 PM Tom Stellard via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> We recently[1] ran into some issues with the mailing lists that caused
>>> us to disable automatic approval of subscriptions.  Over the past few
>>> months, the LLVM Foundation Board of Directors have been investigating
>>> solutions to this issue and are recommending that the project move its
>>> discussion forum from mailman to Discourse[2].
>>>
>>> The proposed migration plan is to move the discussion lists (e.g *-dev,
>>> *-users lists) to Discourse as soon as possible.  The commit email lists
>>> (*-commits lists) will remain on mailman until a not-yet-determined date
>>> in the future, after which they will be replaced by something else.
>>> Some commit lists alternatives include Discourse and GitHub commit
>>> comments (but there may be others).
>>>
>>> Here are the reasons why the LLVM Foundation Board of Directors is
>>> recommending this change:
>>>
>>> - The LLVM project discussion lists cannot be adequately maintained by
>>> our
>>>current volunteer infrastructure staff and without changes we run the
>>>risk of a major outage.
>>>
>>> - We are able to make this change without significant impact to user's or
>>>developer's daily workflows because Discourse supports email
>>> subscriptions
>>>and posting (NOTE: if you are concerned that your workflow may be
>>> impacted
>>>by this change, please contact the Infrastructure Working Group[3], so
>>>they can help test your workflow with Discourse.)
>>>
>>> - Discourse gives us additional features that will benefit the community:
>>>- Easy to signup and subscribe to categories
>>>- Better moderation tools.
>>>- Web-based user interface.
>>>- Ability to send announcements to multiple categories to avoid
>>> having to
>>>  cross-post community wide announcements.
>>>
>>> - A subset of the community (MLIR) have been experimenting with Discourse
>>>for over a year and are able to provide feedback about this experience
>>>to the Board of Directors.
>>>
>>> We did also consider one alternative, which was migrating our lists to a
>>> mailman hosting service.  However, we concluded that with all the work it
>>> would take to migrate our lists to another service, it would be better
>>> if we moved to a service (like Discourse) that provided more features
>>> than what we have now.
>>>
>>> We understand that moving to Discourse is a change for the community and
>>> that people may be worried about this having a negative impact on their
>>> participation in the project.  As mentioned above, w

Re: [lldb-dev] [cfe-dev] Mailing List Status Update

[James Y Knight via lldb-dev]

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 option is global -- all messages in all categories on the llvm
> discourse instance. Which definitely isn't what I want at all. I don't want
> to subscribe to MLIR, for example.
>

FWIW, it would seem that one secret trick here is to NOT check "mailing
list mode" -- that option is mostly there to confuse you, I guess.

In general, I'd say I'm pretty uncomfortable with switching from a mailing
> list to discourse. Discourse seems entirely reasonable to use for
> end-user-facing forums, but I'm rather unconvinced about its suitability as
> a dev-list replacement. Other communities (e.g. python) seem to have a
> split, still: mailing lists for dev-lists, and discourse for
> end-user-facing forums.
>
> I'd also note that Mailman3 provides a lot more features than what we're
> used to with mailman2, including the ability to interact/post through the
> website.
>
> Maybe someone can convince me that I'm just being a curmudgeon, but at
> this point, I'd say we ought to be investigating options to have Someone
> Else manage the mailman service, and keep using mailing lists, rather than
> attempting to switch to discourse.
>

On that last point, I've gone ahead and asked the folks at osci.io ("Open
Source Community Infrastructure") if they'd be willing to host our mailing
lists. They are a group at RedHat whose mission is to support
infrastructure for open-source community projects, and they host mailman3
lists for a number of other open-source groups, already (
https://www.osci.io/tenants/). So, I believe they have the necessary
experience and expertise.

They have said they indeed are willing and have the capacity to run this
for us as a service, if we'd like. We'd still need to be responsible for
things like list moderation, but they'd run the mailman installation on
their infrastructure. In my opinion, we ought to take this option, rather
than trying to push a migration to discourse.

To me, it seems this would be a much clearer upgrade path, and would solve
the hosting/volunteer-admin issue -- including for commit lists -- giving
the current maintainers quicker relief from the undesired task of running
the list service. Additionally, since it would be a migration to Mailman3,
we would get many of the additional features mentioned as desirable, e.g.
searchable archives and posting from the website.

On Tue, Jun 1, 2021 at 4:50 PM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> Hi,
>>
>> We recently[1] ran into some issues with the mailing lists that caused
>> us to disable automatic approval of subscriptions.  Over the past few
>> months, the LLVM Foundation Board of Directors have been investigating
>> solutions to this issue and are recommending that the project move its
>> discussion forum from mailman to Discourse[2].
>>
>> The proposed migration plan is to move the discussion lists (e.g *-dev,
>> *-users lists) to Discourse as soon as possible.  The commit email lists
>> (*-commits lists) will remain on mailman until a not-yet-determined date
>> in the future, after which they will be replaced by something else.
>> Some commit lists alternatives include Discourse and GitHub commit
>> comments (but there may be others).
>>
>> Here are the reasons why the LLVM Foundation Board of Directors is
>> recommending this change:
>>
>> - The LLVM project discussion lists cannot be adequately maintained by our
>>current volunteer infrastructure staff and without changes we run the
>>risk of a major outage.
>>
>> - We are able to make this change without significant impact to user's or
>>developer's daily workflows because Discourse supports email
>> subscriptions
>>and posting (NOTE: if you are concerned that your workflow may be
>> impacted
>>by this change, please contact the Infrastructure Working Group[3], so
>>they can help test your workflow with Discourse.)
>>
>> - Discourse gives us additional features that will benefit the community:
>>- Easy to signup and subscribe to categories
>>- Better moderation tools.
>>- Web-based user interface.
>>- Ability to send announcements to multiple categories to avoid having
>> to
>>  cross-post community wide announcements.
>>
>> - A subset of the community (MLIR) have been experimenting with Discourse
>>for over a year and are able to provide feedback about this experience
>>to the Board of Directors.
>>
>> We did also consider one alternative, which was migrating our lists to a
>> mailman hosting service.  However, we concluded that with all the work it
>> would take to migrate our lists to another service, it would be better
>> if we moved to a service (like Discourse) that provided more features
>> than what we ha

Re: [lldb-dev] [cfe-dev] [llvm-dev] Mailing List Status Update

[James Y Knight via lldb-dev]

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, the first and most basic is I'm worried about having core
> infrastructure out of our own control.  For all their problems, mailing
> lists are widely supported, there are many vendors/contractors available.
> For discourse, as far as I can tell, there's one vendor.  It's very much a
> take it or leave it situation.  The ability to preserve discussion archives
> through a transition away from discourse someday concerns me.  I regularly
> and routinely need to dig back through llvm-dev threads which are years
> old.  I've also recently had some severely negative customer experiences
> with other tools (most recently discord), and the thought of having my
> employability and ability to contribute to open source tied to my ability
> to get a response from customer service teams at some third party vendor I
> have no leverage with, bluntly, scares me.
>
> Second, I feel that we've overstated the difficulty of maintaining mailing
> lists.  I have to acknowledge that I have little first hand experience
> administering mailman, so maybe I'm way off here.
>
> Hi Philip,
>
> First, despite the similar names, Discord is very different than
> Discourse.  Here I’m only commenting about Discourse, I have no opinion
> about Discord.
>
>
> In this case, I think we need to highly weight the opinions of the people
> actively mainlining the existing systems.  It has become clear that the
> priority isn’t “control our own lists”, it is “make sure they stay up” and
> “get LLVM people out of maintaining them”.
>
> The ongoing load of maintaining these lists (including moderation) and of
> dealing with the security issues that keep coming up are carried by several
> individuals, not by the entire community.  I’m concerned about those
> individuals, but I’m also more broadly concerned about *any* individuals
> being solely responsible for LLVM infra.  Effectively every case we’ve had
> where an individual has driving LLVM infra turns out to be a problem.  LLVM
> as a project isn’t good at running web scale infra, but we highly depend on
> it.
>

I agree that the maintenance issue is definitely a problem which needs to
be solved. And there is some urgency, given the recent problems which
resulted in a need to manually subscribe people to the lists.

But, the proposal on the table doesn't appear to actually address this
issue, because the maintainers of llvm mailman will still continue to be
responsible for keeping it functioning, for the mailing lists which were
not proposed to be migrated. On the other hand, having osci.io run a
mailman3 service for us does seem to be a way to solve this -- and doesn't
require discarding mailing lists entirely.

It seems clear to me that we should outsource this to a proven vendor.
> Your concerns about discourse seem very similar to the discussion about
> moving to Github (being a single vendor who was once much smaller than
> Microsoft).  I think your concerns are best addressed by having the IWG
> propose an answer to “what is our plan if Discourse-the-company goes
> sideways?"
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev