Sourceforge is not really user friendly to report issues, propose pull-request and contribute to the project. I would like to know if it is possible to migrate Docutils to GitHub.
Issues can also be reported via mail to the docutils-users list (see Docutils Mailing Lists and our home page__
Provided patches may be against the Git-mirror, too.
Adding a +1 here. I don't mean to be rude, but it's pretty ludicrous in 2020, that such a widely used package is on sourceforge. There is literally no other python package I know of that is not using git (GitHub or GitLab) and it is a massive barrier to contribution.
That fact that, 18 year after its first release, its still not even on its v1 release, when sphinx (IMO the main reason why docutils is still even used) is now on version 3, is pretty indicative of the lack of development on this project.
I'm sure there are many people that want to help you improve this package, please help them to help you!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd also like to +1 this request. These days Git is the go-to solution for starting projects and keeping them going. In fact, even I've never had to learn to use svn. I recall copying some commands back in 2012 to fetch some source but then I've never needed it again. Throughout my career I haven't met anything other then Git with a few exceptions (like perforce) on "neighbor" projects that I didn't participate in.
And since Git became so popular, it's the first thing newbies see when they start figuring out coding in 2020. With time, the number of people who know Git (and never saw svn in their lives) and are familiar with the popular code hosting / social platforms is going to be overwhelmingly higher. Many of them could potentially contribute and help maintain this project but wouldn't want to go through all of the burden of learning a totally foreign mix of ecosystems.
Now, besides the obvious GitHub/GitHub/BitBucket hostings that provide about the same set of the basic colaboration services (like issues/pull requests/CI), there's also others that are more open (as in they are all FOSS). Let me give you some idea about the options with some notes:
https://opendev.org/ — this one comes from the OpenStack ecosystem and consists of a set of open source tools like Gerrit (code review), Zuul (CI — literally the most flexibly configurable of a kind that folks run for FOSS projects), Gitea (browsing source), Etherpad, mediawiki and some more.
https://sr.ht/ — also consists of a collection of tools, connected in an UNIX-style way (componets that follow a single responsibility principle by doing one thing but doing it well). There's a bug tracker, wikis, CI and mailing lists built-in. The most wonderful feature it supports IMHO is the first-class support for email-driven git workflow. This means that contributors don't even need an account on the service — they can send patches over email in a standardized manner ( https://drewdevault.com/2018/07/02/Email-driven-git.html / https://git-send-email.io/). Fun fact: Git itself uses an send-email for their own contribution workflow!
https://pagure.io/ — a Git hosting that is mostly used by Fedora and is sponsored by Red Hat. Though, AFAICS it's open to be used by anybody. Also open source. Has some issues/wiki support. Seems to require an external Jenkins instance for CI.
http://github.com/ — issues/Pull Requests/wiki/CI/huge community/project boards. Doesn't have mailing lists, nor is open source itself. Among advantages: big single-click Apps/integrations ecosystem, has a built-in static website hosting (GitHub Pages).
https://gitlab.com/ — (almost) open source. They say it's open core — the main thing is FOSS and extra features are closed/paid. Has issues/Merge Requests/wiki/CI/somewhat big community/GitLab Pages (static website hosting)/Docker registry/project boards.
Beats me ... since when is the choice of newbies an argument for going
that way.
Sorry - just couldn't help it. I think you will find that a huge
majority of experienced developers would strongly support a switch to
Github, to support both experienced developers, and newbies.
Fortunately for everyone, I can restrain myself from repeating the
arguments as to why I'm sure that is the case.
Cheers,
Matthew
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the list Sviatoslav.
Apart from personal preference, the killer reason I think GitHub though is that sphinx (IMO the main "user" of docutils) is on GitHub, and so this would allow easier cross-referencing between both projects
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't have a strong opinion about migration. Indeed, I prefer to use
GitHub and other modern platforms. But it does not mean Sourceforge
prevents the contribution to docutils. Actually, I've posted some
patches to this project ever. Surely, I must admit I'd needed to
remember how to create a patch file from my git repository every time.
But it's a minor issue to me. So I'm neutral for this topic.
My large concern for this topic is nobody mentioned about the costs of
migration. I think somebody should pay a cost to migrate the project
to GitHub. Especially, I minded the cost of each maintainer. I don't
know how they are familiar with git, GitHub, CI, and so on. I know
openness for new contributors is very important. So I agree it is
worth migrating to well-known platform like GitHub. But I also think
it is important to keep the environment that main maintainers can
works. We have to know the cost of the migration for each maintainer.
I worry about the migration would stop or slow down more the project
(if they need to pay costs for the new platform).
Many thanks for continuous maintaining.
Takeshi KOMIYA
Last edit: Günter Milde 2022-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
migrating code, commit history (with authors) and branches using the GitHub Importer (this takes about 10 minutes),
migrating tickets to issues using a python script that interfaces with the SourceForge and GitHub REST APIs (this is both autonomous and idempotent and takes about 10 minutes).
The main branch derives from the svn trunk, then here on the develop branch this README has been added and a GitHub workflow for Continuous Integration.
I think this covers the majority of a migration?
thanks for the reply Takeshi.
As Inote in https://sourceforge.net/p/docutils/mailman/message/37077728/, unfortunately you are the only person in 2020 to have a patch ticket closed.
I understand your viewpoint, if anyone wants to contribute money then thats great, but I think people will also pay with their time. As shown above, I'm happy to help migrate or even become a maintainer, and I'm sure I am not the only one.
❤️
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The the migration occurs, it would be great to transfer your work there.
Then there are a lot of cleaning, get rid of the sandbox
do you know all uses of the sandbox ?
did you see the quality of patches we get ?
lacking everything, not even some documentation ... from the same people
complaining the documentation of docutils is bad
???? ah i get it some left over april jokes ... and i fell for it .... my
bad sorry
Looks like I have some permissions on the GitHub docutils account. I'd be happy to give permissions to anyone who wants to maintain an official mirror.
In terms of short-term fixes, I wonder if having a GitHub mirror of docutils that accepted Pull Requests would solve a lot of the contribution issues? The core devs could continue to use SF & SVN, but git contributors would be able to use the GitHub workflow they are accustomed to. This seems like a good place to start.
Cheers,
Eric
Last edit: Günter Milde 2022-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
+1 for migrating to GitHub. I second all the benefits mentioned above. I've been moving to GitHub myself with a larger project, and it really makes a difference.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any interest amongst the maintainers/existing contributors to move away from Sourceforge?
If folks wish to stick with Sourceforge and SVN, on principle of avoiding git because it uses hashes / proprietary software like GitHub / Microsoft owned stuff / "centralisation of open source" / something along those lines, could someone explicitly state that? (These are all things I've read on the mailing list archives for this project, but they're from a decent amount of time ago -- people are definitely entitled to changing their opinions as time passes).
I ask becase it would be good to know -- largely because I'm more than happy to leave y'all in peace if you like this platform and want to stick with it. If the migration-related concerns are about the process of the migration rather than the idea of using git + GitHub then, please say so. I'd be happy to explore see what is possible to make that happen (both in terms of my volunteered time, seeking resources to help the process, as well as exploring ways to actually make this migration happen) -- if the currently active contributors and/or David Goodger say they're interested in migrating.
I'm not gonna bother justifying why migrating to a more modern platform will be useful -- if existing contributors still need to be convinced about this today, then I think my time is better spent catering to my other OSS responsibilities like pip and other aspects of the Sphinx ecosystem.
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not contributed to Docutils, apart from some bug reports, but I
have worked on most scientific Python projects, and have several of my
own.
The collaboration features of Git / Github (or Gitlab, or whatever)
are vastly superior to the SVN / Sourceforge equivalents, and this has
obvious consequences in terms of:
Increased quality of community engagement
Size of the developer community.
I'd like to emphasize the first. It may not be obvious, but my
experience is that - the clunkier and more inconvenient the tools, the
lower the quality of the work. It's just because the person doing
the work is spending more time fighting with the tools, and has
consequently less thought time to devote to the quality of the code
and their understanding of the code. By analogy, think what kind of
code you would get if you forced your users to edit the code in
Microsoft Word.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I’d note we have already been through this discussion, it seems at least once a year lol. With https://github.com/chrisjsewell/docutils I have already shown that it is really quite trivial to migrate. I get the strong impression though that the maintainers are against moving. This is absolutely their prerogative, but yeh I think the clear benefits of git vs svn are just not in question at this point
Cheers,
Chris
Last edit: Günter Milde 2022-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
do you know all uses of the sandbox ?
did you see the quality of patches we get ?
lacking everything, not even some documentation ... from the same people
complaining the documentation of docutils is bad
I may have misunderstood, but I took that comment to suggest that
moving to Github was a bad idea because it would encourage more poor
quality patches. In case that was really what Engelbert meant, I was
arguing that it's the poor quality of the Sourceforge infrastructure,
and SVN, that contributes to low-quality patches. Otherwise, it's a
bit difficult to explain why Docutils would get bad patches, when that
is not true for the various other open-source projects I'm involved
in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I know this is a recurring thread - but I was really responding to
this:
On Sun, Aug 9, 2020 at 10:28 PM engelbert gruber via Docutils-develop
docutils-develop@lists.sourceforge.net wrote: [snip]
do you know all uses of the sandbox ?
did you see the quality of patches we get ?
lacking everything, not even some documentation ... from the same people
complaining the documentation of docutils is bad
I may have misunderstood, but I took that comment to suggest that
moving to Github was a bad idea because it would encourage more poor
quality patches. In case that was really what Engelbert meant, I was
arguing that it's the poor quality of the Sourceforge infrastructure,
and SVN, that contributes to low-quality patches. Otherwise, it's a
bit difficult to explain why Docutils would get bad patches, when that
is not true for the various other open-source projects I'm involved
in.
what is difficult in using the git-mirror of docutils
and making good patches ... enlighten me
what difference does it nmake if you send clone from the git-mirror
to a git-master ... is there any ?
Last edit: Günter Milde 2022-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On Thu, 7 Oct 2021 at 13:37, Matthew Brett matthewbrett@users.sourceforge.net wrote:
Yes, I know this is a recurring thread - but I was really responding to
this:
On Sun, Aug 9, 2020 at 10:28 PM engelbert gruber via Docutils-develop
docutils-develop@lists.sourceforge.net wrote: [snip]
do you know all uses of the sandbox ?
did you see the quality of patches we get ?
lacking everything, not even some documentation ... from the same people
complaining the documentation of docutils is bad
I may have misunderstood, but I took that comment to suggest that
moving to Github was a bad idea because it would encourage more poor
quality patches. In case that was really what Engelbert meant, I was
arguing that it's the poor quality of the Sourceforge infrastructure,
and SVN, that contributes to low-quality patches. Otherwise, it's a
bit difficult to explain why Docutils would get bad patches, when that
is not true for the various other open-source projects I'm involved
in.
what is difficult in using the git-mirror of docutils
and making good patches ... enlighten me
what difference does it nmake if you send clone from the git-mirror
to a git-master ... is there any ?
We used to have these discussions in the early days of switching to
Github. It was very difficult to explain to someone who hadn't used
Git and Github, why they were such a massive improvement in workflow.
The breakthrough would always come when, for whatever reason, the
person who was not convinced started to use Git and Github seriously
for code contributions and code review, at which point the objections
just dissolved.
So I guess I have to ask - have you not used Git or Github very much?
I mean, have you used the system for some fairly serious piece of
work, where you have submitted substantial Github pull requests, and
used the Pull Request review system to review code and ask for
changes? I'm asking because I used to use Sourceforge and SVN, a lot
- but I would never go back to that now - and that started when I
started to use Git and Github in earnest, first for our own projects,
in brain imaging,, and later for all the other projects I follow and
contribute to:
It really is like any other improvement in tooling - it takes away
barriers between you and expressing your ideas correctly in code - and
that means better code, from the contributors. And the code review
systems are also a pleasure to use, making reviews easier to do, and
easier to respond to - also making for better code - and, fairly
quickly, better contributors.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
and this isnt even mentioning the comple lack of Continuous Integration testing on sourceforge. with things like GH Actions and https://pre-commit.ci/, it makes it a lot easier to ensure good quality contributions, against unit tests, formatting, linting and documentation etc, significantly reducing the burden on maintainers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It all comes down to entry barrier.
Even when using a docutils mirror on github to fetch the most up-to-date
master,
in order to upstream your change, you will still need to meddle with
mailing lists + source forge + svn.
For me personally, the reason I think the current sourceforge project is
unwelcoming an github/gitlab is superior can be summed up into 3 points:
The sourceforge interface is very outdated, and unlikely to be
updated any time soon.
The method to fetch sources varies from project to project (it's very
inconsistent).
Github/gitlab are very consistent in that regard, a big clone button at
the home page.
Subversion is only used by dinosaurs, unwilling to adapt.
I don't understand why docutils hasn't made the switch to git yet.
Git is superior to subversion in every regard.
Imho, git-svn is not a substitute, but a stop gap.
Students aren't teached subversion anymore. It's git all the way.
Allowing only mail for sending patches raises the bar for sending
patches/improvements.
It might work for the kernel, but that project is of a total other scale
and has a different target audience.
Github/gitlab allows users to easily fork a project, make changes,
commit, push and send their changes upstream.
Mailing lists might work, but you lose a certain audience.
Switching to github might/will result in various/more people opening pull
requests.
Those pr's might be trivial, but some will be big/huge.
Are you ready to handle the possible raise of pull requests?
Is there any interest amongst the maintainers/existing contributors to
move away from Sourceforge?
If folks wish to stick with Sourceforge and SVN, on principle of avoiding
git because it uses hashes / proprietary software like GitHub / Microsoft
owned stuff / "centralisation of open source" / something along those
lines, could someone explicitly state that?
engelbert gruber: I'd appreciate it if you could respond to these questions
directly.
Last edit: Günter Milde 2022-06-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are currently no plans to move to GitHub, sorry.
There is a Git mirror at https://repo.or.cz/w/docutils.git
(cf.
Creating a local git clone__).Issues can also be reported via mail to the
docutils-users list(seeDocutils Mailing Listsand ourhome page__Provided patches may be against the Git-mirror, too.
Hope this helps a bit.
http://docutils.sourceforge.net/docs/user/mailing-lists.html#docutils-users
http://docutils.sourceforge.net/docs/user/mailing-lists.html
http://docutils.sourceforge.net/
http://docutils.sourceforge.net/docs/dev/repository.html#creating-a-local-git-clone
Adding a +1 here. I don't mean to be rude, but it's pretty ludicrous in 2020, that such a widely used package is on sourceforge. There is literally no other python package I know of that is not using git (GitHub or GitLab) and it is a massive barrier to contribution.
That fact that, 18 year after its first release, its still not even on its v1 release, when sphinx (IMO the main reason why docutils is still even used) is now on version 3, is pretty indicative of the lack of development on this project.
I'm sure there are many people that want to help you improve this package, please help them to help you!
I'd also like to +1 this request. These days Git is the go-to solution for starting projects and keeping them going. In fact, even I've never had to learn to use svn. I recall copying some commands back in 2012 to fetch some source but then I've never needed it again. Throughout my career I haven't met anything other then Git with a few exceptions (like perforce) on "neighbor" projects that I didn't participate in.
And since Git became so popular, it's the first thing newbies see when they start figuring out coding in 2020. With time, the number of people who know Git (and never saw svn in their lives) and are familiar with the popular code hosting / social platforms is going to be overwhelmingly higher. Many of them could potentially contribute and help maintain this project but wouldn't want to go through all of the burden of learning a totally foreign mix of ecosystems.
Now, besides the obvious GitHub/GitHub/BitBucket hostings that provide about the same set of the basic colaboration services (like issues/pull requests/CI), there's also others that are more open (as in they are all FOSS). Let me give you some idea about the options with some notes:
Last edit: Sviatoslav Sydorenko 2020-08-06
Beats me ... since when is the choice of newbies an argument for going
that way.
The interesting thing to me is which arguments come up 😂 like the
distributed thing which is no longer valid it seams.
Cheers
Last edit: Günter Milde 2022-06-01
Hi,
On Mon, Nov 15, 2021 at 3:06 PM engelbert gruber via Docutils-develop
docutils-develop@lists.sourceforge.net wrote:
Sorry - just couldn't help it. I think you will find that a huge
majority of experienced developers would strongly support a switch to
Github, to support both experienced developers, and newbies.
Fortunately for everyone, I can restrain myself from repeating the
arguments as to why I'm sure that is the case.
Cheers,
Matthew
Thanks for the list Sviatoslav.
Apart from personal preference, the killer reason I think GitHub though is that sphinx (IMO the main "user" of docutils) is on GitHub, and so this would allow easier cross-referencing between both projects
I see much more reasons:
Hi folks,
I don't have a strong opinion about migration. Indeed, I prefer to use
GitHub and other modern platforms. But it does not mean Sourceforge
prevents the contribution to docutils. Actually, I've posted some
patches to this project ever. Surely, I must admit I'd needed to
remember how to create a patch file from my git repository every time.
But it's a minor issue to me. So I'm neutral for this topic.
My large concern for this topic is nobody mentioned about the costs of
migration. I think somebody should pay a cost to migrate the project
to GitHub. Especially, I minded the cost of each maintainer. I don't
know how they are familiar with git, GitHub, CI, and so on. I know
openness for new contributors is very important. So I agree it is
worth migrating to well-known platform like GitHub. But I also think
it is important to keep the environment that main maintainers can
works. We have to know the cost of the migration for each maintainer.
I worry about the migration would stop or slow down more the project
(if they need to pay costs for the new platform).
Many thanks for continuous maintaining.
Takeshi KOMIYA
Last edit: Günter Milde 2022-06-01
Cross-posting from
Note I have now created: https://github.com/chrisjsewell/docutils: https://github.com/sphinx-doc/sphinx/issues/8039#issuecomment-671081278
As it states in the README, this package shows how a migration can be done in a very simple, autonomous manner:
The main branch derives from the svn trunk, then here on the develop branch this README has been added and a GitHub workflow for Continuous Integration.
I think this covers the majority of a migration?
thanks for the reply Takeshi.
As Inote in
https://sourceforge.net/p/docutils/mailman/message/37077728/, unfortunately you are the only person in 2020 to have a patch ticket closed.
I understand your viewpoint, if anyone wants to contribute money then thats great, but I think people will also pay with their time. As shown above, I'm happy to help migrate or even become a maintainer, and I'm sure I am not the only one.
Fixing formatting issues above:
Cross-posting from https://github.com/sphinx-doc/sphinx/issues/8039#issuecomment-671081278
Note I have now created: https://github.com/chrisjsewell/docutils
....
Wonderful ! I saw you also set a GitHub workflow which is awesome!
Notice that somebody already have an unmaintened mirror there: https://github.com/docutils/docutils
The the migration occurs, it would be great to transfer your work there.
Then there are a lot of cleaning, get rid of the
sandboxor automigrating these as separate branches. Perhaps https://github.com/chrisjsewell/docutils/tree/develop/docutils should be set as the new root. The web part can be placed in another repository.What do you think?
On Sun, 9 Aug 2020 at 21:20, Yves Chevallier nowox@users.sourceforge.net
wrote:
???? ah i get it some left over april jokes ... and i fell for it .... my
bad sorry
Last edit: Günter Milde 2022-06-01
Cheers, well yes anything is possible, I first wanted to show that its not a particularly arduous task.
Note I have also now added CI test coverage https://codecov.io/gh/chrisjsewell/docutils
Hey Eric,
I was actually already meaning to mention to you, that you also have ownership of https://readthedocs.org/projects/docutils/ https://readthedocs.org/projects/docutils/
Which was 4 years outdated, but now I see there’s a recent build, so looks like you dug it back up from the grave lol
Just to note also, this message does not show up on the actual ticket thread: https://sourceforge.net/p/docutils/feature-requests/58/ https://sourceforge.net/p/docutils/feature-requests/58/
This is the second time I’ve seen this happen in the last few days (the other being Jeffrey’s reply) .
Last edit: Günter Milde 2022-06-01
+1 for migrating to GitHub. I second all the benefits mentioned above. I've been moving to GitHub myself with a larger project, and it really makes a difference.
Hello there!
Is there any interest amongst the maintainers/existing contributors to move away from Sourceforge?
If folks wish to stick with Sourceforge and SVN, on principle of avoiding git because it uses hashes / proprietary software like GitHub / Microsoft owned stuff / "centralisation of open source" / something along those lines, could someone explicitly state that? (These are all things I've read on the mailing list archives for this project, but they're from a decent amount of time ago -- people are definitely entitled to changing their opinions as time passes).
I ask becase it would be good to know -- largely because I'm more than happy to leave y'all in peace if you like this platform and want to stick with it. If the migration-related concerns are about the process of the migration rather than the idea of using git + GitHub then, please say so. I'd be happy to explore see what is possible to make that happen (both in terms of my volunteered time, seeking resources to help the process, as well as exploring ways to actually make this migration happen) -- if the currently active contributors and/or David Goodger say they're interested in migrating.
I'm not gonna bother justifying why migrating to a more modern platform will be useful -- if existing contributors still need to be convinced about this today, then I think my time is better spent catering to my other OSS responsibilities like pip and other aspects of the Sphinx ecosystem.
I have not contributed to Docutils, apart from some bug reports, but I
have worked on most scientific Python projects, and have several of my
own.
The collaboration features of Git / Github (or Gitlab, or whatever)
are vastly superior to the SVN / Sourceforge equivalents, and this has
obvious consequences in terms of:
I'd like to emphasize the first. It may not be obvious, but my
experience is that - the clunkier and more inconvenient the tools, the
lower the quality of the work. It's just because the person doing
the work is spending more time fighting with the tools, and has
consequently less thought time to devote to the quality of the code
and their understanding of the code. By analogy, think what kind of
code you would get if you forced your users to edit the code in
Microsoft Word.
I’d note we have already been through this discussion, it seems at least once a year lol. With https://github.com/chrisjsewell/docutils I have already shown that it is really quite trivial to migrate. I get the strong impression though that the maintainers are against moving. This is absolutely their prerogative, but yeh I think the clear benefits of git vs svn are just not in question at this point
Cheers,
Chris
Last edit: Günter Milde 2022-06-01
Yes, I know this is a recurring thread - but I was really responding to this:
On Sun, Aug 9, 2020 at 10:28 PM engelbert gruber via Docutils-develop
docutils-develop@lists.sourceforge.net wrote:
[snip]
I may have misunderstood, but I took that comment to suggest that
moving to Github was a bad idea because it would encourage more poor
quality patches. In case that was really what Engelbert meant, I was
arguing that it's the poor quality of the Sourceforge infrastructure,
and SVN, that contributes to low-quality patches. Otherwise, it's a
bit difficult to explain why Docutils would get bad patches, when that
is not true for the various other open-source projects I'm involved
in.
On Thu, 7 Oct 2021 at 13:37, Matthew Brett matthewbrett@users.sourceforge.net wrote:
what is difficult in using the git-mirror of docutils
and making good patches ... enlighten me
what difference does it nmake if you send clone from the git-mirror
to a git-master ... is there any ?
Last edit: Günter Milde 2022-06-01
On Wed, Oct 13, 2021 at 11:35 PM engelbert gruber via Docutils-develop
docutils-develop@lists.sourceforge.net wrote:
We used to have these discussions in the early days of switching to
Github. It was very difficult to explain to someone who hadn't used
Git and Github, why they were such a massive improvement in workflow.
The breakthrough would always come when, for whatever reason, the
person who was not convinced started to use Git and Github seriously
for code contributions and code review, at which point the objections
just dissolved.
So I guess I have to ask - have you not used Git or Github very much?
I mean, have you used the system for some fairly serious piece of
work, where you have submitted substantial Github pull requests, and
used the Pull Request review system to review code and ask for
changes? I'm asking because I used to use Sourceforge and SVN, a lot
- but I would never go back to that now - and that started when I
started to use Git and Github in earnest, first for our own projects,
in brain imaging,, and later for all the other projects I follow and
contribute to:
https://github.com/matthew-brett/
It really is like any other improvement in tooling - it takes away
barriers between you and expressing your ideas correctly in code - and
that means better code, from the contributors. And the code review
systems are also a pleasure to use, making reviews easier to do, and
easier to respond to - also making for better code - and, fairly
quickly, better contributors.
and this isnt even mentioning the comple lack of Continuous Integration testing on sourceforge. with things like GH Actions and https://pre-commit.ci/, it makes it a lot easier to ensure good quality contributions, against unit tests, formatting, linting and documentation etc, significantly reducing the burden on maintainers
what is so hard about the question: i really would like to know: so i
repeat it
is there a difference if you clone from the docutils-mirror on github
to cloning from a docutils master on github ?
thanks for your kindness
Last edit: Günter Milde 2022-06-01
It all comes down to entry barrier.
Even when using a docutils mirror on github to fetch the most up-to-date
master,
in order to upstream your change, you will still need to meddle with
mailing lists + source forge + svn.
Using the docutils-mirror is not even a possibility, because it is severely
outdated:
https://github.c https://github.com/docutils-mirror/docutils
om/docutils-mirror/docutils https://github.com/docutils-mirror/docutils
(last commit was 6+ years ago)
For me personally, the reason I think the current sourceforge project is
unwelcoming an github/gitlab is superior can be summed up into 3 points:
updated any time soon.
The method to fetch sources varies from project to project (it's very
inconsistent).
Github/gitlab are very consistent in that regard, a big clone button at
the home page.
I don't understand why docutils hasn't made the switch to git yet.
Git is superior to subversion in every regard.
Imho, git-svn is not a substitute, but a stop gap.
Students aren't teached subversion anymore. It's git all the way.
patches/improvements.
It might work for the kernel, but that project is of a total other scale
and has a different target audience.
Github/gitlab allows users to easily fork a project, make changes,
commit, push and send their changes upstream.
Mailing lists might work, but you lose a certain audience.
Switching to github might/will result in various/more people opening pull
requests.
Those pr's might be trivial, but some will be big/huge.
Are you ready to handle the possible raise of pull requests?
I didn't look much for other's experiences in migrating to
git/github/gitlab,
but I found this little testimonial:
https://twitter.com/reactos/status/1445641745685835780
To summarize, it's not because it's working for you (=the developer(s))
that it works for the community.
Best regards
Maarten
Last edit: Günter Milde 2022-06-01
engelbert gruber: I'd appreciate it if you could respond to these questions
directly.
Last edit: Günter Milde 2022-06-01