Re: Maintaining mono/.net
Hi, On 09-07-2016 kl. 13:10 Romain Tartière wrote: Dear all, I finally could manage to sync my local mess into some "shipable form" and updated the bsd-sharp github repository with current WIP: https://github.com/smortex/bsd-sharp My main issue is devel/newtonsoft-json which fails to build. I could not manage to get more time to search for the root cause of the build failure during the last couple of weeks :-( If someone has insights or a workaround, thank you for sharing ! I dont know know if any others are looking at his issue ? fyi. I could build lang/mono from the repository without any changes. I will take a look devel/newtonsoft-json and see if I can fix it. Regards, Romain Carsten ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
Hey everyone, Thanks so much for your input. I'm really glad to have these discussions. Romain, your "2 cents" are very insiteful and already within days the repositories I cloned were outdated. I can see the limits of the tools much as you have described them. So, I have gone back and asked myself, "what the hell is it you are trying to do?" The answer is not "maintain repositories". The answer is "bring together a community that cares about FreeBSD where people with mono/.net skills to contribute". The mono stack was outdated until a few hours ago, (awesome job Romain, can't wait to test your patches) and there was no clear documentation on what needs to happen and who is participating. These discussions seem to have pushed things in the right direction regardless of the FreeBSD-DotNet github project. Romain has already patched fsharp (I just did that last night), mono and some others. FreeBSD doesn't accept Github Pull Requests so the ports patches need to be pushed through Bugzilla and/or Phabricator in the end anyway. We can do all of this in svn, bugzilla and phabricator (and thanks for the offer koobs!). I hope that all our patches wind up upstream. In fact, I would prefer all of that. However, GitHub is the tool-of-the-day and there are some primitive tools to manage these things. Moreover, I don't have to ask anyones permission. SO, the FreeBSD-DotNet project is about community. I have created a developers wiki here: https://github.com/FreeBSD-DotNet/Developer-Wiki There is not much in it yet, but by the end of the week I will have some process around issues and whatnot as these are the tools available. If you want to show your support for Mono and Dot-Net on FreeBSD via GitHub, feel free to send me a request and become a member. I hope that members will help keep the issues updated so there is a place we can see what is happening. As members we can push patches to a community location, or not as the individual so chooses. BUT if we can track issues, put together better documentation, share patches, and improve the quality of DotNet through community, then I think that's a good thing. Ivan has some patches as well and I'll get those up there asap. Ivan, if you have some ideas for GH process you want to see, then now is the time to voice that. In the end, if the site is not helpful, then so be it. But lets give it a shot, shall we? Russ On Sat, Jul 9, 2016 at 4:30 AM, Kubilay Kocak wrote: > On 28/06/2016 4:06 AM, Russell Haley wrote: >> Hello Ports Team, >> >> A couple of us on the freebsd-mono@ mailing list are having a >> discussion on how best to maintain the mono ports/.net ports. One of >> the things that has come up is maintaining the patches for "all this >> stuff". The current paradigm in FreeBSD as I understand it is to use >> the files directory and apply the patches to the port via svn/ports >> tree. However, with the ubiquity of GitHub in opensource, it now seems >> to be feesable to simply create a Github accound to maintain a bunch >> of forked repositories (which is essentially a patched git >> repository!). This makes it easier to create and apply patches and >> gives us the natural path to push things back upstream. In the end, we >> would just pull from the FreeBSD specific repository, which is no >> different than, say, pulling from the mono project directly. >> >> This email is a request for response from anyone on the ports team (or >> FreeBSD general) to give some input as to the acceptability of this >> solution, as well as any "gotchas" we haven't thought of yet. Thanks >> in advance! >> >> >> Russ > > Hi Russ, > > If all the things can't eventually end up upstream, and even if they > ultimately could, there's no issues with your own github repository to > maintain a 'freebsd branch'. > > We have other teams/projects doing just that, such as > freebsd-ports-gnome, freebsd-ports-graphics among others. > > I'll go one beyond that and say I'd (as a part of Git Admin) be happy to > create a repository under the official freebsd organisation for you, > perhaps named "freebsd-ports-mon"o or similar, with the members of 'team > mono' added as writers. > > Hit me up off-list (cc git-admin@) to discuss further > > -- > Regards, > > Kubilay > Git Admin > > > ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On 28/06/2016 4:06 AM, Russell Haley wrote: > Hello Ports Team, > > A couple of us on the freebsd-mono@ mailing list are having a > discussion on how best to maintain the mono ports/.net ports. One of > the things that has come up is maintaining the patches for "all this > stuff". The current paradigm in FreeBSD as I understand it is to use > the files directory and apply the patches to the port via svn/ports > tree. However, with the ubiquity of GitHub in opensource, it now seems > to be feesable to simply create a Github accound to maintain a bunch > of forked repositories (which is essentially a patched git > repository!). This makes it easier to create and apply patches and > gives us the natural path to push things back upstream. In the end, we > would just pull from the FreeBSD specific repository, which is no > different than, say, pulling from the mono project directly. > > This email is a request for response from anyone on the ports team (or > FreeBSD general) to give some input as to the acceptability of this > solution, as well as any "gotchas" we haven't thought of yet. Thanks > in advance! > > > Russ Hi Russ, If all the things can't eventually end up upstream, and even if they ultimately could, there's no issues with your own github repository to maintain a 'freebsd branch'. We have other teams/projects doing just that, such as freebsd-ports-gnome, freebsd-ports-graphics among others. I'll go one beyond that and say I'd (as a part of Git Admin) be happy to create a repository under the official freebsd organisation for you, perhaps named "freebsd-ports-mon"o or similar, with the members of 'team mono' added as writers. Hit me up off-list (cc git-admin@) to discuss further -- Regards, Kubilay Git Admin ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
Dear all, I finally could manage to sync my local mess into some "shipable form" and updated the bsd-sharp github repository with current WIP: https://github.com/smortex/bsd-sharp My main issue is devel/newtonsoft-json which fails to build. I could not manage to get more time to search for the root cause of the build failure during the last couple of weeks :-( If someone has insights or a workaround, thank you for sharing ! Regards, Romain -- Romain Tartière http://people.FreeBSD.org/~romain/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) signature.asc Description: PGP signature
Re: Maintaining mono/.net
Hi Guys, The FreeBSD-DotNet repositories are up to date. Ivan, please feel free to make changes and/or add a freebsd branch. I changed the permissions so that all members have read and write privileges for all repositories. So once again, feel free to submit your git handle/username to me via this mailing list and I'll add you to the group. I've started to add todo items to the issue tracker. Cheers, Russ On Tue, Jul 5, 2016 at 12:59 PM, Russell Haley wrote: > On Tue, Jul 5, 2016 at 11:12 AM, Carsten Larsen wrote: >> ON 05-07-2016 kl. 17:06 Ivan Radovanovic wrote: >>> >>> >>> I had some spare time during weekend so I was playing little bit with >>> mono - I cloned mono repository, then branched "freebsd" from their 4.4 >>> branch (which is maybe also nice coincidence (freebsd and bsd4.4)), then >>> I merged all our changes in that branch - I added Romain's patches to >>> eglib, I added my implementation of FS watcher to System.dll, I also >>> added test for FS watcher to test cases (so hopefully it will be easier >>> to spot errors), I also fixed just couple of warning in C code they have >>> in main mono source (there are many warnings there, some look serious to >>> me - my plan is to keep reducing their number). >>> >> >> It sounds like a good start. 4.4.0 could be our head (read: master). >> >>> Instead of changing their Kevent watcher implementation I added this one >>> as completely new FS watcher (FreeBSD watcher), and I modified >>> mono/metadata/filewatcher.c to always use this watcher when compiled on >>> FreeBSD (I don't know about kevent implementation on other BSDs - maybe >>> FreeBSD implementation should be used there as well). >>> >>> All mono tests pass (running gmake check), but those related to profiler >>> (they segfault in native code - I am planning to investigate that >>> further). >>> >>> Btw, I am configuring mono with: >>> >>> ./configure --disable-dtrace --with-checked-build=yes >>> >>> since if I leave dtrace enabled I get billion linking errors later (I >>> will investigate that at certain point as well). >>> >>> Now, the question is how I push these changes to repository Russ created >>> (is that repository we want to use for this project)? I am also not >>> familiar enough with git to know if this setup now will work (we were >>> talking to have our local repositories to talk to main mono repository >>> for reading, and our (fbsd) repository for writing (to keep patches), >>> now actual setup is that repository Russ created is forked from mono (I >>> don't know if that changes anything)). Maybe somebody can clarify this? >>> >>> Kind regards, >>> Ivan >> >> >> The fork in github.com/FreeBSD-DotNet/mono made by Russ is forked directly >> from master. Its not really a candidate for merging. >> >> If you would like to push those changes to github.com/FreeBSD-DotNet/mono >> you would first need to make your own user of github. With this user you can >> fork mono again and then clone you own mono repository to you local PC. >> Transfer your changes this this local repository and commit at usual. >> >> Or Russ could make a new fork on github equivalent to: >> git clone -b mono-4.4.0-branch https://github.com/mono/mono.git > > Ivan has just answered alot of this and is now on the freebsd-dotnet > team. Here were my thoughts: > > I think all Ivan needs to do is: > > git remote set-url origin https://github.com/freebsd-dotnet/mono.git > > then to verify: > > git remote -v > > and then git-commit and git-push > > Instructions are here: > https://help.github.com/articles/changing-a-remote-s-url/#platform-linux > > However I think that will break things because we are 60 commits > behind head and 4 behind the 4.4 branch. I will update the repository > tonight. > > OR > > Ivan can do a git-diff on the current repository, clone the > FreeBSD-dotnet repository and then apply the patch using git-apply > > https://git-scm.com/docs/git-diff > > https://git-scm.com/docs/git-apply > > (old news: I've sent an freebsd-dotnet invitation to the Ivan > Radovanovic user just in case.) > >> Then he could invite you (read: your github user) as a collaborate of this >> new repository. You would then be able to push your changes directly to >> github.com/FreeBSD-DotNet/mono-dev (or whatever name is chosen). >> >> It could be a nice experiment but as Romain Tartière mentioned earlier in >> the thread we are not suppose to break any existing mono ports. I don’t know >> how to validate all the existing ports against a new release (candidate) but >> I assume it would be done using poudriere. > > A list can be seen at > http://www.freshports.org/search.php?stype=depends_run&method=match&query=mono&num=10&orderby=category&orderbyupdown=asc&search=Search > > and we can work on the plan to get that going. I suggest we document > these ideas in https://github.com/FreeBSD-DotNet/Developer-Wiki/wiki > > > Cheers, > > Russ ___ freebsd-mono@freebsd.org mailing list ht
Re: Maintaining mono/.net
On Tue, Jul 5, 2016 at 11:12 AM, Carsten Larsen wrote: > ON 05-07-2016 kl. 17:06 Ivan Radovanovic wrote: >> >> >> I had some spare time during weekend so I was playing little bit with >> mono - I cloned mono repository, then branched "freebsd" from their 4.4 >> branch (which is maybe also nice coincidence (freebsd and bsd4.4)), then >> I merged all our changes in that branch - I added Romain's patches to >> eglib, I added my implementation of FS watcher to System.dll, I also >> added test for FS watcher to test cases (so hopefully it will be easier >> to spot errors), I also fixed just couple of warning in C code they have >> in main mono source (there are many warnings there, some look serious to >> me - my plan is to keep reducing their number). >> > > It sounds like a good start. 4.4.0 could be our head (read: master). > >> Instead of changing their Kevent watcher implementation I added this one >> as completely new FS watcher (FreeBSD watcher), and I modified >> mono/metadata/filewatcher.c to always use this watcher when compiled on >> FreeBSD (I don't know about kevent implementation on other BSDs - maybe >> FreeBSD implementation should be used there as well). >> >> All mono tests pass (running gmake check), but those related to profiler >> (they segfault in native code - I am planning to investigate that >> further). >> >> Btw, I am configuring mono with: >> >> ./configure --disable-dtrace --with-checked-build=yes >> >> since if I leave dtrace enabled I get billion linking errors later (I >> will investigate that at certain point as well). >> >> Now, the question is how I push these changes to repository Russ created >> (is that repository we want to use for this project)? I am also not >> familiar enough with git to know if this setup now will work (we were >> talking to have our local repositories to talk to main mono repository >> for reading, and our (fbsd) repository for writing (to keep patches), >> now actual setup is that repository Russ created is forked from mono (I >> don't know if that changes anything)). Maybe somebody can clarify this? >> >> Kind regards, >> Ivan > > > The fork in github.com/FreeBSD-DotNet/mono made by Russ is forked directly > from master. Its not really a candidate for merging. > > If you would like to push those changes to github.com/FreeBSD-DotNet/mono > you would first need to make your own user of github. With this user you can > fork mono again and then clone you own mono repository to you local PC. > Transfer your changes this this local repository and commit at usual. > > Or Russ could make a new fork on github equivalent to: > git clone -b mono-4.4.0-branch https://github.com/mono/mono.git Ivan has just answered alot of this and is now on the freebsd-dotnet team. Here were my thoughts: I think all Ivan needs to do is: git remote set-url origin https://github.com/freebsd-dotnet/mono.git then to verify: git remote -v and then git-commit and git-push Instructions are here: https://help.github.com/articles/changing-a-remote-s-url/#platform-linux However I think that will break things because we are 60 commits behind head and 4 behind the 4.4 branch. I will update the repository tonight. OR Ivan can do a git-diff on the current repository, clone the FreeBSD-dotnet repository and then apply the patch using git-apply https://git-scm.com/docs/git-diff https://git-scm.com/docs/git-apply (old news: I've sent an freebsd-dotnet invitation to the Ivan Radovanovic user just in case.) > Then he could invite you (read: your github user) as a collaborate of this > new repository. You would then be able to push your changes directly to > github.com/FreeBSD-DotNet/mono-dev (or whatever name is chosen). > > It could be a nice experiment but as Romain Tartière mentioned earlier in > the thread we are not suppose to break any existing mono ports. I don’t know > how to validate all the existing ports against a new release (candidate) but > I assume it would be done using poudriere. A list can be seen at http://www.freshports.org/search.php?stype=depends_run&method=match&query=mono&num=10&orderby=category&orderbyupdown=asc&search=Search and we can work on the plan to get that going. I suggest we document these ideas in https://github.com/FreeBSD-DotNet/Developer-Wiki/wiki Cheers, Russ ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On 07/05/2016 18:06, Russell Haley wrote: The rub with GitHub is that there is no way to auto-magically keep a fork up to date, meaning as soon as you create a fork and apply patches, it becomes possible to get out of date without manual updates. That means it becomes the teams job to make sure we keep our repositories current (or get all patches pushed upstream). So, there are three ways that I know of to sync your changes *assuming they under git currently*: 1) via pull requests 2) via raw patches 3) switching the remote origin, pulling the changes, then switching again (?) I have to go now, so let us know where your changes are. I'm not sure if you can create pull requests between forks of the same repo, it will be neat to try. If you are unfamiliar with pushing your changes back to your remote repository, I always used this: https://rogerdudler.github.io/git-guide/ My idea of doing this was something like this (I am much less familiar with github): $ git clone url-to-mono-rep $ git checkout branch-4.4 $ git branch freebsd $ git checkout freebsd ... doing some work ... $ git remote add freebsd url-to-our-rep $ git push freebsd freebsd # pushing freebsd branch to our repo for pulling new development from mono $ git checkout master $ git pull origin master merging mono changes with ours $ git checkout freebsd $ git merge master (warning: high probability that I made some mistake with git commands above) In addition to this "freebsd" branch we should have one more stable branch, which would require code to be reviewed to reach it. P.S. I got invite for github (thanks Russ!), I will first test how to push this with some dummy remote I will create (in my experience mistaken commits to central repository can be annoying to fix). ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On 07/05/2016 20:12, Carsten Larsen wrote: ON 05-07-2016 kl. 17:06 Ivan Radovanovic wrote: All mono tests pass (running gmake check), but those related to profiler (they segfault in native code - I am planning to investigate that further). This is actually not true, because of little bit of healthy paranoia I had tests running dozen times or so, one of them is crashing at random times (pinvoke3 - this is big one using lot of native functions, probably it will be difficult to trace down). The fork in github.com/FreeBSD-DotNet/mono made by Russ is forked directly from master. Its not really a candidate for merging. If you would like to push those changes to github.com/FreeBSD-DotNet/mono you would first need to make your own user of github. With this user you can fork mono again and then clone you own mono repository to you local PC. Transfer your changes this this local repository and commit at usual. Or Russ could make a new fork on github equivalent to: git clone -b mono-4.4.0-branch https://github.com/mono/mono.git I think this setup we are after has to provide two things for us: 1. us to be able to easily keep and maintain set of patches we need to make FreeBSD first class mono platform (ie us doing programming) 2. to be able to easily pull and merge changes done by upstream (ie to benefit from somebody else doing programming) I know if I run my repository with 2 remotes I can easily pull from one and push (and pull) to the other (obviously one to only pull from would be mono), but what confuses me now is if the fact that this repository Russ created is in fact forked from that same mono changes something or not? (maybe we can use only that repository without having 2 remotes in local git?) Everything I did is in git repository. (In reply to Russ) It could be a nice experiment but as Romain Tartière mentioned earlier in the thread we are not suppose to break any existing mono ports. I don’t know how to validate all the existing ports against a new release (candidate) but I assume it would be done using poudriere. Carsten This one I don't really know how to do, ideally tests supplied with mono should be enough (and realistically, they probably are not), I guess we could simply install mono built this way on one of those VMs, and then try to run several of those other ports and see what happens? Kind regards, Ivan ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
ON 05-07-2016 kl. 17:06 Ivan Radovanovic wrote: I had some spare time during weekend so I was playing little bit with mono - I cloned mono repository, then branched "freebsd" from their 4.4 branch (which is maybe also nice coincidence (freebsd and bsd4.4)), then I merged all our changes in that branch - I added Romain's patches to eglib, I added my implementation of FS watcher to System.dll, I also added test for FS watcher to test cases (so hopefully it will be easier to spot errors), I also fixed just couple of warning in C code they have in main mono source (there are many warnings there, some look serious to me - my plan is to keep reducing their number). It sounds like a good start. 4.4.0 could be our head (read: master). Instead of changing their Kevent watcher implementation I added this one as completely new FS watcher (FreeBSD watcher), and I modified mono/metadata/filewatcher.c to always use this watcher when compiled on FreeBSD (I don't know about kevent implementation on other BSDs - maybe FreeBSD implementation should be used there as well). All mono tests pass (running gmake check), but those related to profiler (they segfault in native code - I am planning to investigate that further). Btw, I am configuring mono with: ./configure --disable-dtrace --with-checked-build=yes since if I leave dtrace enabled I get billion linking errors later (I will investigate that at certain point as well). Now, the question is how I push these changes to repository Russ created (is that repository we want to use for this project)? I am also not familiar enough with git to know if this setup now will work (we were talking to have our local repositories to talk to main mono repository for reading, and our (fbsd) repository for writing (to keep patches), now actual setup is that repository Russ created is forked from mono (I don't know if that changes anything)). Maybe somebody can clarify this? Kind regards, Ivan The fork in github.com/FreeBSD-DotNet/mono made by Russ is forked directly from master. Its not really a candidate for merging. If you would like to push those changes to github.com/FreeBSD-DotNet/mono you would first need to make your own user of github. With this user you can fork mono again and then clone you own mono repository to you local PC. Transfer your changes this this local repository and commit at usual. Or Russ could make a new fork on github equivalent to: git clone -b mono-4.4.0-branch https://github.com/mono/mono.git Then he could invite you (read: your github user) as a collaborate of this new repository. You would then be able to push your changes directly to github.com/FreeBSD-DotNet/mono-dev (or whatever name is chosen). It could be a nice experiment but as Romain Tartière mentioned earlier in the thread we are not suppose to break any existing mono ports. I don’t know how to validate all the existing ports against a new release (candidate) but I assume it would be done using poudriere. Carsten ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On Tue, Jul 5, 2016 at 8:06 AM, Ivan Radovanovic wrote: > On 06/30/2016 06:31, Russell Haley wrote: >> >> ... >> Apparently I was mistaken, there is no way to "apply" to an >> organization. Please feel free to send me your handle like David, and >> I'll add you. >> >> And just in case anyone is fuzzy on GitHub access: There is no need to >> join the FreeBSD-DotNet organization to create pull requests (i.e. >> push patches) and our end products should wind up in the Ports tree >> when we are done. >> > > I had some spare time during weekend so I was playing little bit with mono - > I cloned mono repository, then branched "freebsd" from their 4.4 branch > (which is maybe also nice coincidence (freebsd and bsd4.4)), then I merged > all our changes in that branch - I added Romain's patches to eglib, I added > my implementation of FS watcher to System.dll, I also added test for FS > watcher to test cases (so hopefully it will be easier to spot errors), I > also fixed just couple of warning in C code they have in main mono source > (there are many warnings there, some look serious to me - my plan is to keep > reducing their number). > > Instead of changing their Kevent watcher implementation I added this one as > completely new FS watcher (FreeBSD watcher), and I modified > mono/metadata/filewatcher.c to always use this watcher when compiled on > FreeBSD (I don't know about kevent implementation on other BSDs - maybe > FreeBSD implementation should be used there as well). > > All mono tests pass (running gmake check), but those related to profiler > (they segfault in native code - I am planning to investigate that further). > > Btw, I am configuring mono with: > > ./configure --disable-dtrace --with-checked-build=yes > > since if I leave dtrace enabled I get billion linking errors later (I will > investigate that at certain point as well). > > Now, the question is how I push these changes to repository Russ created (is > that repository we want to use for this project)? I am also not familiar > enough with git to know if this setup now will work (we were talking to have > our local repositories to talk to main mono repository for reading, and our > (fbsd) repository for writing (to keep patches), now actual setup is that > repository Russ created is forked from mono (I don't know if that changes > anything)). Maybe somebody can clarify this? > > Kind regards, > Ivan That's awesome Ivan! That really kicks things up a notch. A git fork is really nothing more than a set of patches applied to the original repository. Therefore, we either manually maintain the patches through the ports tree (via someone with a commit bit), or we push to github and then everyone can share your work without centralized supervision. If mono decides to accept our pull requests, then fine, otherwise, 'to-hell-with-em'. The rub with GitHub is that there is no way to auto-magically keep a fork up to date, meaning as soon as you create a fork and apply patches, it becomes possible to get out of date without manual updates. That means it becomes the teams job to make sure we keep our repositories current (or get all patches pushed upstream). So, there are three ways that I know of to sync your changes *assuming they under git currently*: 1) via pull requests 2) via raw patches 3) switching the remote origin, pulling the changes, then switching again (?) I have to go now, so let us know where your changes are. I'm not sure if you can create pull requests between forks of the same repo, it will be neat to try. If you are unfamiliar with pushing your changes back to your remote repository, I always used this: https://rogerdudler.github.io/git-guide/ Cheers, Russ p.s. I have tried some things with MD but still can't get around the PCL error. I'll write about that later. ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On 06/30/2016 06:31, Russell Haley wrote: ... Apparently I was mistaken, there is no way to "apply" to an organization. Please feel free to send me your handle like David, and I'll add you. And just in case anyone is fuzzy on GitHub access: There is no need to join the FreeBSD-DotNet organization to create pull requests (i.e. push patches) and our end products should wind up in the Ports tree when we are done. I had some spare time during weekend so I was playing little bit with mono - I cloned mono repository, then branched "freebsd" from their 4.4 branch (which is maybe also nice coincidence (freebsd and bsd4.4)), then I merged all our changes in that branch - I added Romain's patches to eglib, I added my implementation of FS watcher to System.dll, I also added test for FS watcher to test cases (so hopefully it will be easier to spot errors), I also fixed just couple of warning in C code they have in main mono source (there are many warnings there, some look serious to me - my plan is to keep reducing their number). Instead of changing their Kevent watcher implementation I added this one as completely new FS watcher (FreeBSD watcher), and I modified mono/metadata/filewatcher.c to always use this watcher when compiled on FreeBSD (I don't know about kevent implementation on other BSDs - maybe FreeBSD implementation should be used there as well). All mono tests pass (running gmake check), but those related to profiler (they segfault in native code - I am planning to investigate that further). Btw, I am configuring mono with: ./configure --disable-dtrace --with-checked-build=yes since if I leave dtrace enabled I get billion linking errors later (I will investigate that at certain point as well). Now, the question is how I push these changes to repository Russ created (is that repository we want to use for this project)? I am also not familiar enough with git to know if this setup now will work (we were talking to have our local repositories to talk to main mono repository for reading, and our (fbsd) repository for writing (to keep patches), now actual setup is that repository Russ created is forked from mono (I don't know if that changes anything)). Maybe somebody can clarify this? Kind regards, Ivan ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
Hi David, Apparently I was mistaken, there is no way to "apply" to an organization. Please feel free to send me your handle like David, and I'll add you. And just in case anyone is fuzzy on GitHub access: There is no need to join the FreeBSD-DotNet organization to create pull requests (i.e. push patches) and our end products should wind up in the Ports tree when we are done. Cheers, Russ On Wed, Jun 29, 2016 at 12:58 PM, Russell Haley wrote: > Interesting. Sorry about that, I will add you and look into it asap. > > Russ > > Sent from my BlackBerry 10 smartphone on the Koodo network. > Original Message > From: David Naylor > Sent: Wednesday, June 29, 2016 12:36 PM > To: Russell Haley > Subject: Re: Maintaining mono/.net > > Hi Russell, > > There doesn't appear to be any way to request being added to the FreeBSD- > DotNet organisation via the link below. > > Would you please consider adding me this organisation. My GitHub handle is > DragonSA. > > Regards, > > On Tuesday, 28 June 2016 22:46:09 Russell Haley wrote: >> On Tue, Jun 28, 2016 at 2:43 AM, Baptiste Daroussin > wrote: >> > On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote: >> >> Hello Ports Team, >> >> >> >> A couple of us on the freebsd-mono@ mailing list are having a >> >> discussion on how best to maintain the mono ports/.net ports. One of >> >> the things that has come up is maintaining the patches for "all this >> >> stuff". The current paradigm in FreeBSD as I understand it is to use >> >> the files directory and apply the patches to the port via svn/ports >> >> tree. However, with the ubiquity of GitHub in opensource, it now seems >> >> to be feesable to simply create a Github accound to maintain a bunch >> >> of forked repositories (which is essentially a patched git >> >> repository!). This makes it easier to create and apply patches and >> >> gives us the natural path to push things back upstream. In the end, we >> >> would just pull from the FreeBSD specific repository, which is no >> >> different than, say, pulling from the mono project directly. >> >> >> >> This email is a request for response from anyone on the ports team (or >> >> FreeBSD general) to give some input as to the acceptability of this >> >> solution, as well as any "gotchas" we haven't thought of yet. Thanks >> >> in advance! >> > >> > There are absolutely nothing against this. Actually some ports were >> > already >> > doing that before the github era :D >> > >> > The only difficulty the history told us is : when active people get less >> > active for various reasons you need to make sure enough people continues >> > to get access to the said repo. >> > >> > Tracking upstream updates because more complicated for people not in the >> > team (we already saw in the past ports stucked for more than 5/6 years >> > actions being taken (maintainer of the forked becoming mostly MIA) >> > >> > It also depends how many patches you end up with, I haven't checked the >> > mono/.net ports but if that is just a bunch of small patches then the >> > overhead is not worth the pain, if there are lots of patches then sure >> > maintaining your repo is simpler. >> > >> > Depending on how active you (the team) are and how close to the upstream >> > you are one can also see those repositories as "temporary" until all the >> > amount of patches are upstreamed and when done the ports can switch back >> > to the official distfiles (this is always a goal for ports upstreaming >> > all our patches so we can remain as close as possible from the vanilla >> > sources) >> > >> > That said I do applause the effort. As a conclusion do what ever you think >> > is the easiest mechanism for you as long as things like monodevelop and >> > friends can be pushed in a working state again. >> > >> > Best regards, >> > Bapt >> >> Thanks for the input everyone. I think the overhead of keeping >> volatile patches in a globally accessible area is worth while. One of >> the things I struggled with historically is how to share my local >> changes that I couldn't commit to the svn tree. >> >> I have created an open source organization called FreeBSD-DotNet in >> Github. I have differentiated from the Mono moniker because the >> merging of the frameworks is inevitable with the purchase of Xamarian.
Re: Maintaining mono/.net
On Tue, Jun 28, 2016 at 2:43 AM, Baptiste Daroussin wrote: > On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote: >> Hello Ports Team, >> >> A couple of us on the freebsd-mono@ mailing list are having a >> discussion on how best to maintain the mono ports/.net ports. One of >> the things that has come up is maintaining the patches for "all this >> stuff". The current paradigm in FreeBSD as I understand it is to use >> the files directory and apply the patches to the port via svn/ports >> tree. However, with the ubiquity of GitHub in opensource, it now seems >> to be feesable to simply create a Github accound to maintain a bunch >> of forked repositories (which is essentially a patched git >> repository!). This makes it easier to create and apply patches and >> gives us the natural path to push things back upstream. In the end, we >> would just pull from the FreeBSD specific repository, which is no >> different than, say, pulling from the mono project directly. >> >> This email is a request for response from anyone on the ports team (or >> FreeBSD general) to give some input as to the acceptability of this >> solution, as well as any "gotchas" we haven't thought of yet. Thanks >> in advance! >> > There are absolutely nothing against this. Actually some ports were already > doing that before the github era :D > > The only difficulty the history told us is : when active people get less > active > for various reasons you need to make sure enough people continues to get > access > to the said repo. > > Tracking upstream updates because more complicated for people not in the team > (we already saw in the past ports stucked for more than 5/6 years actions > being > taken (maintainer of the forked becoming mostly MIA) > > It also depends how many patches you end up with, I haven't checked the > mono/.net ports but if that is just a bunch of small patches then the overhead > is not worth the pain, if there are lots of patches then sure maintaining your > repo is simpler. > > Depending on how active you (the team) are and how close to the upstream you > are > one can also see those repositories as "temporary" until all the amount of > patches are upstreamed and when done the ports can switch back to the official > distfiles (this is always a goal for ports upstreaming all our patches so we > can > remain as close as possible from the vanilla sources) > > That said I do applause the effort. As a conclusion do what ever you think is > the easiest mechanism for you as long as things like monodevelop and friends > can > be pushed in a working state again. > > Best regards, > Bapt Thanks for the input everyone. I think the overhead of keeping volatile patches in a globally accessible area is worth while. One of the things I struggled with historically is how to share my local changes that I couldn't commit to the svn tree. I have created an open source organization called FreeBSD-DotNet in Github. I have differentiated from the Mono moniker because the merging of the frameworks is inevitable with the purchase of Xamarian. I went a little crazy and forked a whole bunch of stuff, which I now think is a bad idea. The only thing that currently requires customization would be the ports tree itself (MonoDevelop doesn't build yet, but I haven't needed to change any code). However, I think we can put a bunch of how-to and wiki stuff in there for the development efforts. SO, with that: Anyone wishing to join the FreeBSD-DotNet organization can go to https://github.com/FreeBSD-DotNet and send a request. I'll try to flesh out an outstanding items list that can be ratified sometime in the next couple of weeks. Thanks, Russ ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
On Mon, Jun 27, 2016 at 11:06:02AM -0700, Russell Haley wrote: > Hello Ports Team, > > A couple of us on the freebsd-mono@ mailing list are having a > discussion on how best to maintain the mono ports/.net ports. One of > the things that has come up is maintaining the patches for "all this > stuff". The current paradigm in FreeBSD as I understand it is to use > the files directory and apply the patches to the port via svn/ports > tree. However, with the ubiquity of GitHub in opensource, it now seems > to be feesable to simply create a Github accound to maintain a bunch > of forked repositories (which is essentially a patched git > repository!). This makes it easier to create and apply patches and > gives us the natural path to push things back upstream. In the end, we > would just pull from the FreeBSD specific repository, which is no > different than, say, pulling from the mono project directly. > > This email is a request for response from anyone on the ports team (or > FreeBSD general) to give some input as to the acceptability of this > solution, as well as any "gotchas" we haven't thought of yet. Thanks > in advance! > There are absolutely nothing against this. Actually some ports were already doing that before the github era :D The only difficulty the history told us is : when active people get less active for various reasons you need to make sure enough people continues to get access to the said repo. Tracking upstream updates because more complicated for people not in the team (we already saw in the past ports stucked for more than 5/6 years actions being taken (maintainer of the forked becoming mostly MIA) It also depends how many patches you end up with, I haven't checked the mono/.net ports but if that is just a bunch of small patches then the overhead is not worth the pain, if there are lots of patches then sure maintaining your repo is simpler. Depending on how active you (the team) are and how close to the upstream you are one can also see those repositories as "temporary" until all the amount of patches are upstreamed and when done the ports can switch back to the official distfiles (this is always a goal for ports upstreaming all our patches so we can remain as close as possible from the vanilla sources) That said I do applause the effort. As a conclusion do what ever you think is the easiest mechanism for you as long as things like monodevelop and friends can be pushed in a working state again. Best regards, Bapt signature.asc Description: PGP signature
Re: Maintaining mono/.net
On 06/27/2016 20:21, Kurt Jaeger napisa: Hi! A couple of us on the freebsd-mono@ mailing list are having a discussion on how best to maintain the mono ports/.net ports. One of the things that has come up is maintaining the patches for "all this stuff". The current paradigm in FreeBSD as I understand it is to use the files directory and apply the patches to the port via svn/ports tree. However, with the ubiquity of GitHub in opensource, it now seems to be feesable to simply create a Github accound to maintain a bunch of forked repositories (which is essentially a patched git repository!). From my point of view, while not perfect, it sounds reasonable. We are open for all (good) ideas (good in sense: easier to use, requiring less effort to maintain patches) :-) ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Re: Maintaining mono/.net
Hi! > A couple of us on the freebsd-mono@ mailing list are having a > discussion on how best to maintain the mono ports/.net ports. One of > the things that has come up is maintaining the patches for "all this > stuff". The current paradigm in FreeBSD as I understand it is to use > the files directory and apply the patches to the port via svn/ports > tree. However, with the ubiquity of GitHub in opensource, it now seems > to be feesable to simply create a Github accound to maintain a bunch > of forked repositories (which is essentially a patched git > repository!). >From my point of view, while not perfect, it sounds reasonable. -- p...@opsec.eu+49 171 3101372 4 years to go ! ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
Maintaining mono/.net
Hello Ports Team, A couple of us on the freebsd-mono@ mailing list are having a discussion on how best to maintain the mono ports/.net ports. One of the things that has come up is maintaining the patches for "all this stuff". The current paradigm in FreeBSD as I understand it is to use the files directory and apply the patches to the port via svn/ports tree. However, with the ubiquity of GitHub in opensource, it now seems to be feesable to simply create a Github accound to maintain a bunch of forked repositories (which is essentially a patched git repository!). This makes it easier to create and apply patches and gives us the natural path to push things back upstream. In the end, we would just pull from the FreeBSD specific repository, which is no different than, say, pulling from the mono project directly. This email is a request for response from anyone on the ports team (or FreeBSD general) to give some input as to the acceptability of this solution, as well as any "gotchas" we haven't thought of yet. Thanks in advance! Russ ___ freebsd-mono@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-mono To unsubscribe, send any mail to "freebsd-mono-unsubscr...@freebsd.org"
