On Sat, 10 Sep 2022, 09:35 Vincent Delecroix, <20100.delecr...@gmail.com> wrote:
> Hello, > > I am in the same mood as Travis : if I was to consider a move to > github I would like to have a clear and complete overview of the > changes in the workflow (how do we set ticket dependencies? how > reviews will work? management of releases? etc). For me the discussion > in this thread is very premature as there is no proposal of this sort. > The "moving to github" does not specify how things will work. > I am sure we can work out reasonable workflows once we have the infrastructure (in particular tickets moved to github's issues) in place. There need not be one single model; as you know, it's perfectly possible to have named branches on GitHub, and use them instead of PRs. And/or we can merge PRs into integration branches, which are then used by Volker for beta and other releases. Many projects merge PRs directly into the master branch, though. We can try this, see if it works. There are many options and possibilities, and choosing one in advance is not very meaningful. I don't want to work on a detailed description of a workflow until we have in principle agreement on the move. Doing such a detailed proposal without a prior agreement is akin to writing a grant application, with a high probability it is rejected, and all the effort for nothing. Been there many times, and no, thanks, I don't like this model of moving things forward, it is too wasteful. > I see clear advantages of moving to github. The first being trac > maintenance and a second example that William mentioned is that it > might lower the barrier for newcomers. But there are also plenty of > reasons not to migrate. The first one I think is that we might loose > active developers. Let me recall that the move from mercurial to git > some 10 years ago made many active developers quit. > I don't recall who quit just due to unwillingness to learn git, not for other, unrelated to the move reasons, using the move as a pretext to get out. Moving from a patch-quilt model to a proper system with branches etc was basically a necessity then, there was too much bitrot going on. Moving away from trac is basically a necessity now, as our devops are breaking down for some time, and it only gets worse. > So I would like to propose that ticket #30363 instead of being > technical (ie how do we do the move) explains > - a concrete proposal for a github workflow (there might be several of > them) > - list the pros > - list the cons > Then we could proceed with a reasonable discussion on whether we will > do such move. > > Ideally (if we had illimited developer time) I would like to encourage > the possibility of having both trac and github. If I recall correctly, > it was possible to authenticate to trac with github account and make > PR on github this is semi-broken now - new accounts have to be added manually, and we don't know how to fix this part of trac/gitolite. that automatically transformed into a ticket on trac. > this was never in place. There is something like this gitlab-based, but it's not in a good shape now, at all. Dima > > Best > Vincent > > On Sat, 10 Sept 2022 at 09:54, Dima Pasechnik <dimp...@gmail.com> wrote: > > > > > > > > On Sat, 10 Sep 2022, 05:48 Matthias Koeppe, <matthiaskoe...@gmail.com> > wrote: > >> > >> On Friday, September 9, 2022 at 9:34:16 PM UTC-7 Travis Scrimshaw wrote: > >>> > >>> I really dislike Github's decentralized approach with PR and having to > have separate clones of the repo within each user. My understanding is if > two people have different fixes, then they individually submit PRs that are > not explicitly linked with each other, much less with a specific bug report > issue. > >> > >> > >> In the PR you would include a comment such as "Fixes #1234", which > links it to an Issue (bug report). > > > > > > and this Issue will then automatically get a comment/mention linking to > the PR, no manual intervention in the Issue is needed. > > > > > >> Yes, there can be multiple competing PRs in order solve one ticket. > Better than edit wars on a Trac ticket. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups "sage-devel" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+unsubscr...@googlegroups.com. > >> To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/2548301a-19d8-4ab5-ab1c-84f3fdcf5bbcn%40googlegroups.com > . > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CAAWYfq3rdAfkj%3DkDLJa0TxMPxLHz4O2_stffO8F-PyiGsO0ZqQ%40mail.gmail.com > . > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CAGEwAAkYpD4fh%3D_QvuwmZoRSgrF6AgUeg1WWvbXMhX-DJ5hanA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3JcRtQWyVeBmAWt2JNzfv5HcdPwKh8%2BjwpnZzaXAkpTA%40mail.gmail.com.
