--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
But if you want to use the github issue tracker then that wouldn't work as easily. I don't think we even can import our current trac database, not to mention that some fields (e.g. Reviewer) are missing.
Following up on this, that we don't fully support people doing
development for Sage by creating independent pip-installable packages
--
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+...@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
What I mostly dislike about github is that "issues" and "pull requests"
are different things. I very much prefer the trac model where you create
a ticket, discuss things, then have multiple people work together on a
branch all on the same page. With github, it sometimes happens that you
have one issue and several pull requests by different people which are
all about the same thing. I get lost more easily in the github forest.
Another useful thing is that everything on trac is in one git tree. I
can do "git fetch" and have all tickets ready to check out without any
hassle. I don't know if you can easily checkout a pull request from github.
Finally a stupid thing: I don't get why github discussions don't have a
"reply" button.
And I agreed with something in the post: just
pay attention to people who are clearly willing to do the job.
I only see a potential increase of the number of pull
requests. Which would actually be bad since we have a lot of pending
tickets.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/95f0cc64-3f5e-494c-83f4-7c1127ae3a36n%40googlegroups.com.
On Thu, Dec 10, 2020 at 10:49 AM David Roe <roed...@gmail.com> wrote:
>
> For Zulip, zulipchat.com provides free hosting for open source projects. I'm fairly confident that we could export our history and import it to a new organization there fairly easily, if there's a consensus to do so.
I don't think we even need a consensus for this. Lack of funds is a
sufficient reason to migrate.
(apart from the history, account data is important...)
We then can point zulip.sagemath.org to the appropriate url at zulipchat.com
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1YEG9_8cP0RjTQmDCMKnphNXL15hqXvGwmVLhkXFt7Rg%40mail.gmail.com.
On Thu, Dec 10, 2020 at 10:50 AM Vincent Delecroix
<20100.d...@gmail.com> wrote:
>
> All the services (= trac + wiki + zulip) could plausibly be hosted
> by CNRS in France. There are dedicated servers for this purpose. If
> it is accepted, the institute will support the cost.
>
> I am available to open the server and discuss with the institute.
> However, I won't have time to do any work on the migration.
How reliable are they? Needless to say, something that goes down and
stays down for a week in August (vacation!)
is not what we can agree to.
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/05a659d7-48c6-4fd0-9ead-fa48701c2190n%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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGG4CB5oiSVA3W3AJWfosLuMuzEKPaoHZ_DWNS58H%3DFgast98w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_mN8PRRt2Ot7YcHqcZGLXPoPcVS0_R_QdjCVYpZHpi5Ng%40mail.gmail.com.
It should be sagemath.zulipchat.com right? (Instead of .org)
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CA%2B01voOy5SXXkyQeqMB-AxeGMXEv5MN%2Bj3FBdYB1DihHHh0inQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3ceNRJoTcEWUCQBTO0cwGk_CRnbwGqBArsLnxM1w7Ctg%40mail.gmail.com.
the futre of the trac software itself.
the futre of the trac software itself.According to their developer mailing listthe future of trac seems not so ominous to me.
Perhaps publishing our fork of trac with customized plugins (?) to sagemath github repo may help increase the bus factor about our own trac
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/c5050c0a-3bcb-4f01-af40-ff3e7a8cb393n%40googlegroups.com.
By not using GitHub we are losing many potential contributors to Sage.
GitHub is by far the most popular site for hosting of open source
projects, and potential Sage developers are likely to be familiar with
GitHub. Not using GitHub adds a huge barrier to entry for Sage
development.
- wiki is academically hosted and works pretty well.
Fees to the Sage community: 0$ per year
Hi,
"[prompted by FUNDING issues!!!]" ???
Back in 2016, when cloud hosting was imposed over academic hosting,
William promised "to pay for it indefinitely", see
https://groups.google.com/g/sage-devel/c/ed_ya-d-k_E/m/jYoR6opODAAJ
If only for this reason, there is no funding issue.
The fact is that the the magic cloud ideology turned into a disaster,
years after years, from askbot in 2014 (thanks again to Niles and OSU
sysadmins for their involvement in its academic hosting during six
years !), to the wiki a few months ago, and now trac+git.
I have been involved in rescuing those services, and putting them back
in a safe place.
What do the facts tell us about academic hosting, in
2022 ?
- askbot is academically hosted and works pretty well.
Fees to the Sage community: 0$ per year
- patchbot server is academically hosted and works pretty well.
Fees to the Sage community: 0$ per year
- I bet that most patchbot clients are run from academic desktops.
Fees to the Sage community: 0$ per year
- wiki is academically hosted and works pretty well.
Fees to the Sage community: 0$ per year
- the backup server (which currently backs up askbot and wiki) is
academically hosted and works pretty well.
Fees to the Sage community: 0$ per year
- most download mirrors are academically hosted and work pretty well.
Fees to the Sage community: 0$ per year
For this reason also, and given the number of universities around the
world, there is no funding issue. The rest is FUD.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20220909144801.GA19110%40metelu.net.
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.
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. It is not so uncommon that people end up working on competing proposals or on the same branch, both of which are not natural using Githubs PR system (I am not even entirely sure how I should do this either; Do I have to clone from their repo? Is it the same remote? Where is the documentation on this? Can I still access the branch if someone deletes their account?). How do other projects at the scale of Sage deal with this?
Honestly, I doubt we are loosing that many quality contributors by not using Github's system since we can have people with GH login's to access trac.
Getting the login credentials was the biggest barrier; everything else is mostly straightforward and based on very simple git commands.
Right now, I find there are way too many practical questions and barriers for how we develop that make moving to Git**b a much bigger pain that people will think it is.
Some of this could be my lack of experience with Github (and a bit of "get off my lawn with your facegrams"), but right now I feel like the move to Github is like starting a car to go to the party in the next town without learning how to drive, much less knowing the route.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4e8fe22b-6538-4a1b-a2c4-620127934e48n%40googlegroups.com.
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).
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+...@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAGEwAAkYpD4fh%3D_QvuwmZoRSgrF6AgUeg1WWvbXMhX-DJ5hanA%40mail.gmail.com.
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 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.
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
that automatically transformed into a ticket on trac.
Best
Vincent
On Sat, 10 Sept 2022 at 09:54, Dima Pasechnik <dim...@gmail.com> wrote:
>
>
>
> On Sat, 10 Sep 2022, 05:48 Matthias Koeppe, <matthia...@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+...@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+...@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+...@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.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAKQMtir03oQsrdJb06_%2Bi4cdVDtxAdZ8pszcbw3C0juqi87mXA%40mail.gmail.com.
HiIn 2020, 21, 22, _only_ Edgewall & Trac-hacks (the trac people), and sagemath are listed as trac users bothering to update their details.I don't know how accurate the below articles are, but found them intersting to read. Would be interested incomments from anyone who knows where they are inaccurate:https://www.incredibuild.com/blog/gitlab-vs-github-comparison (Flow and CI sections)I can't tell which workflow is better for sagemath. Remember feature parity betweenm them will also change every few months!Also see what they say about themselves/each other:It does look like github might offer more contributors. (Of high and low quality? Perhaps the slight hurdle to logging in to gitlab the first time is a good thing...)I'd be happy to assist with self-hosting (so gitlab) and perhaps sponsor a container (even a separate machine for CI) but I think the sagemath project would probably be better off on git**b. I'm also hesitant to invest my time in learning trac/gitolite. The bus problem Dima mentioned with self-hosting is valid. But nice to have it as an option for a quick exit (from either git**b) when whatever happens to the companies...
I don't think the move is so urgent though, but it should probably happen in the next year or so.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAg%3Dp_2KD6ZDiY9VKD7RDzNNne%2B5WLg0Cqt7VMyRDvVepyWS7Q%40mail.gmail.com.
Hi all,I'm only an occasional developer with sage, but I wanted to also bring up one (minor) positive for moving to github which is less technical. Moving to github would be a motivating factor for people to contribute to sagemath as it gives a pathway to work in industry (programming) if they chose to leave academia. In particular, github shows contributions made by a user to various projects. This could be a valuable tool for someone on the job market who would prefer (or has no choice) to move to industry and get a programming job. Sure, one can already currently say that one develops for sagemath, but by putting it on github it creates a unified location for future employers to look. As mentioned, this is just a minor positive, but could be a motivating factor for some.
Also, I concur with Vincent in that we should have somewhere with a list of pros/cons for either side in some kind of list fashion as currently it's a little hard to keep track of whether people are making the same arguments or new arguments.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAKQMtir03oQsrdJb06_%2Bi4cdVDtxAdZ8pszcbw3C0juqi87mXA%40mail.gmail.com.
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. It is not so uncommon that people end up working on competing proposals or on the same branch, both of which are not natural using Githubs PR system (I am not even entirely sure how I should do this either; Do I have to clone from their repo? Is it the same remote? Where is the documentation on this? Can I still access the branch if someone deletes their account?). How do other projects at the scale of Sage deal with this?It seems you never reviewed a non-trivial PR on GitHub, no?
Well, you can go and have a look how e.g. CPython does it, or SciPy.
The PR process and the underlying structure is very well-documented.
A PR creates a branch in the git repo of the "main"project. This is really not much different from what we do on trac, except that the branch namesatisfied different rules.
E.g. using https://github.com/scipy/scipy/pull/14786 as an example, the underlying branch in the repo of scipy isnamed pull/14786.To examine it locally on your machine you can use plain git to fetch it, or you can use GitHub'stool called cli (its functionality is close to what git-trac does, not sure if you use or used git-trac, though).
It stays there even if the user GitHub account is closed (the latter triggers an automatic closure of the PR, but the underlyingbranch remains in the repo, it can be worked on just the same using git)
Besides, nobody forces you to use a PR to review something. You can open an issue, and ask for a specific branch somewhere (in a fork, or even in a completely unrelated git branch hosted outside of GitHub) to be reviewed, and only do a PR once the branch in question is stabilized.
Honestly, I doubt we are loosing that many quality contributors by not using Github's system since we can have people with GH login's to access trac.except that this is broken now, (along with automatic management of ssh keys in general) and one needsa tricky manual process (modifying a special gitolite git repo used by trac) by one of trac adminsto add/modify ssh keys.(and I am not even sure whether this manual process does not lead to an eventual breakage of the ssh keystore, it's all tied upwith trac in a rather arcane way).
Getting the login credentials was the biggest barrier; everything else is mostly straightforward and based on very simple git commands.Right now, I find there are way too many practical questions and barriers for how we develop that make moving to Git**b a much bigger pain that people will think it is.Travis, many people nowadays never used git without GitHub or GitLab. For such a person it's a major pain tolearn our workflow.
Some of this could be my lack of experience with Github (and a bit of "get off my lawn with your facegrams"), but right now I feel like the move to Github is like starting a car to go to the party in the next town without learning how to drive, much less knowing the route.What's the alternative?
Would you like to contribute your time to do our time-consuming trac etc devops?
Anyway, trac is obsolete software used mainly to maintain legacy projects which don't even use git,and we'd have to move sooner or later to something that is robust and maintained, and is not an endlesstimesink to keep working. And trac is only a part of the general Sage devops nightmare, created largerly bysticking to semi-obsolete tools for too long.I think you have pointed at exactly one question - you didn't know how to deal with git branches of GitHub's PR.
I hope you see now that it's trivial. Do you have any other objections?
Just to give a different perspective, from someone who is not a Sage developer but is a Sage donor, the only reason I give money to Sage every month is because I happened to see your appeal on GitHub.
If you had no GitHub presence at all, I likely would not be a donor. Not because I would not want to support Sage in that scenario, but because I would not know you needed money and there would not be a button I could just press to give you some (and I am not the only one, according to https://github.com/sponsors/sagemath there are 25 of us and you currently receive about $3000/year in donations made through GitHub).
I think the same principle applies to attracting donations of time rather than money, and these are much more important to the health of an open source project. The pool of potential Sage contributors you might attract on GitHub is vastly larger than the pool of people who are motivated enough to figure out how to make contributions via trac. Yes, you will get plenty of junk PRs you have to deal with on GitHub, but that does not require a lot of effort and I think it would be well worth it for the sake of the non-junk PRs you might get (whose main value is not the code but the person behind it who might submit more PRs in the future if you make it easy for them to do so). Indeed, I can even imagine myself fixing the occasional bug I come across in Sage if all I had to do was submit a PR on GitHub, and there are surely many Sage users who might become Sage contributors if the activation cost were low enough.
I also think Aram Dermenjian made an excellent point -- in today's world the value of being able to point to contributions to projects on GitHub vastly exceeds the value of being able to point to a contribution you made on trac (regardless of the merits of the contribution or the project itself). This does not apply just to professional software developers, it also applies to students who might be your best source of future Sage developers.
I've enabled wikis on our GitHub and startedPlease feel free to add content there.
I wanted to also bring up one (minor) positive for moving to github which is less technical. Moving to github would be a motivating factor for people to contribute to sagemath as it gives a pathway to work in industry (programming) if they chose to leave academia. In particular, github shows contributions made by a user to various projects. This could be a valuable tool for someone on the job market who would prefer (or has no choice) to move to industry and get a programming job. Sure, one can already currently say that one develops for sagemath, but by putting it on github it creates a unified location for future employers to look. As mentioned, this is just a minor positive, but could be a motivating factor for some.
On Fri, Sep 9, 2022 at 7:58 PM Thierry <sage-goo...@lma.metelu.net> wrote:
>
> On Fri, Sep 09, 2022 at 04:07:48PM +0100, Dima Pasechnik wrote:
> [...]
> >
> > Several people promised to look for academic hosting for trac. Nothing
> > came out of it.
>
> Please do not rewrite history, as it adds violence to violence. There
> have indeed been offers for academic hosting, the VM were ready, but the
> cloud hosting was enforced, and you was promoting this.
I don't recall any concrete offer like this. If I recall correctly,
the problem of accessing VMs in French
universities for outsiders have never been resolved in a meaningful
way, leading to an unacceptably small
for the project bus factor.
By the way, another proof of my small bus factor claim is here:
https://trac.sagemath.org/ticket/33725#comment:30
Apparently you want to do everything your way, and your way only.
You are asked to provide the wiki contents in a suitable for import
form, and you just pretend you didn't see the request?
Matthias Koeppe wrote:
> I've added a draft of a proposed workflow on GitHub with the idea to
> just follow the Trac workflow.
In my eyes at least, it is a defect of our current workflow that tickets
are used for tracking both bugs and proposed enhancements. On git**b,
wouldn't it be more natural to use issues for, well, issues (that is,
bug reports, as opposed to bug *fixes* or enhancements) and pull
requests for proposed changes?
Matthias Koeppe wrote:
> Yes, of course, and that's what I am documenting
> at https://github.com/sagemath/sage/wiki/migration-from-trac-to-Git**b
Sorry, apparently I misunderstood your proposal.
I would suggest the following changes then:
"Instead of opening a Trac ticket"
--> "To report a bug, instead of opening a Trac ticket"
""Bug"/"Enhancement" is mapped to "Labels""
--> "No "Bug"/"Enhancement" distinction (use pull requests to submit
enhancements)"
I've added a draft of a proposed workflow on GitHub with the idea to just follow the Trac workflow.Help is welcome in adding links to documentation for the various bits.I think we can have a fleshed out Trac to GitHub transition guide by the end of the weekend.
If so, who can edit it?
--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4420889b-a904-4ef8-9743-037648e7640cn%40googlegroups.com.
Matthias Koeppe schrieb am Samstag, 10. September 2022 um 21:32:50 UTC+2:On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe wrote:I've added a draft of a proposed workflow on GitHub with the idea to just follow the Trac workflow.Help is welcome in adding links to documentation for the various bits.I think we can have a fleshed out Trac to GitHub transition guide by the end of the weekend.A draft of the Trac-to-GitHub transition guide is now available at:Please let me know what's missing or unclear.What will be the replacement for the ticket description? Just the first comment of the issue reprectively PR?yesIf so, who can edit it?anyone with write access to the repo.
Matthias Koeppe schrieb am Samstag, 10. September 2022 um 21:32:50 UTC+2:On Saturday, September 10, 2022 at 8:12:48 AM UTC-7 Matthias Koeppe wrote:I've added a draft of a proposed workflow on GitHub with the idea to just follow the Trac workflow.Help is welcome in adding links to documentation for the various bits.I think we can have a fleshed out Trac to GitHub transition guide by the end of the weekend.A draft of the Trac-to-GitHub transition guide is now available at:Please let me know what's missing or unclear.What will be the replacement for the ticket description? Just the first comment of the issue reprectively PR?yesIf so, who can edit it?anyone with write access to the repo.
A draft of the Trac-to-GitHub transition guide is now available at:Please let me know what's missing or unclear.