I did CI for my gnunet project. Github and bitbucket have CI that I've worked with.
https://travis-ci.org/cheako/gnunetircd On Fri, Mar 30, 2018, 12:46 PM Catonano <[email protected]> wrote: > Hello > > this is the first time I write on this mailing list > > I should probably introduce myself but Iì m not exact6ly comfortable with > introductions > > I' m not an academic, not even a professional. I'm an hobbyist > > This is the list of my contributions to Guix > http://git.savannah.gnu.org/cgit/guix.git/log/?qt=author&q=catonano > > > 2018-03-28 7:05 GMT+02:00 Christian Grothoff <[email protected]>: > >> Hi xrs, >> >> I guess I should briefly chime in here with my perspective: >> >> 1) Yes, in January things briefly looked like there might be some >> velocity, but the usual work then came back for me (and I am sure most >> of you), slowing things down to the usual crawl. Several people had >> talked to me about possibilities of funding in Dec/Jan as well, but none >> of it happened (so far, and some possibilities turned into definitive >> "no"s). I also was mistaken about how quickly CI/Web >> site/documentation/bugfixes would happen. But, with an all-volunteer >> crew, things naturally move very slowly. >> > > I sent some patches to Ng0 when they were migrating the documentation from > the old format to TexInfo > > My patches eliminated a ton of errors and warnings that the texinfo tools > were erupting at the time > > I thought the work on the documentation was finished > > If it' s not, I could try to contribute some more > > Is the documentation process stuck ? Where, exactly ? > > > >> >> 2) As for the release _criteria_, I had proposed a few simple minimal >> requirements everybody seemed to agree upon at the time: (1) passing >> testcases, (2) no compiler warnings / serious issues found in static >> analysis, (3) passes 'acceptance' test where we manually try key >> features in the GUI(s). I think I also had as highly desirable (4) >> working/passing CI/BB and (5) new Web site with current documentation, >> but I'm (in principle) willing to forgo those. Also, we can decide to >> cut out subsystems (psyc, multicast, psycstore, etc.) if those do not >> pass tests and nothing else depends upon them. So if we get this, I'm >> generally happy to 'make dist' a new TGZ, which is 'making a release'. >> >> 3) What you are discussing is more the *development* process. We >> already have branches. We have seen how merging branches for a release >> can create wonderful additional chaos and delays because the branch >> worked for the dev, but not on other systems --- and merging 100 patches >> from a branch (as usual with insufficient unit tests) then makes for fun >> debugging when you actually want to get a release done. So without >> better CI and better tests, they can do about as much harm as good. I am >> all for "do not break master" and "only commit new code that builds and >> passes tests to master". That won't fix the strange existing/random-ish >> test failures we do have for a while now. For that, it would take better >> tests, and people with the time to write them, and write them well. >> > > Again, I could try to contribute some tests > > I could use an introduction about how to build and run the project right > now, preferably using Guix based tools/environments > > And then if there's any indication of where is the coverage lacking, that > coudl be useful > > > >> Today, we sometimes have bugfixes in a branch not backported to master, >> or branches that have not been rebased to master lacking bugfixes from >> master. Wonderful. As maintainer, it's hard enough for me to keep track >> of mainline/master and my own branches/developments. I cannot also >> manually cherry-pick bugfixes from branches, and so far *many* >> developers have been really shitty at merging their branches in a timely >> fashion (and by "timely", I can point to examples in the time range of >> within a few years). >> > > I' m sorry to learn that > > >> So please, do feel free to use branches, but more importantly, write >> good tests, make sure they pass, and merge if they do. Also, do setup a >> CI, make sure the CI runs the tests on a wide array of systems, make >> sure master *passes* the tests, and _then_ we can impose a 'do not break >> master' regime for commits. > > > What does it take to setup a CI ? > > I hear that Gitlab has some powerful CI tools, could they help ? > > Again, can I help with this ? > > Thanks > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers >
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
