gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Towards a new formalized release policy


From: Mike Mestnik
Subject: Re: [GNUnet-developers] Towards a new formalized release policy
Date: Fri, 30 Mar 2018 18:50:56 +0000

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 <address@hidden> 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
2018-03-28 7:05 GMT+02:00 Christian Grothoff <address@hidden>:
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
address@hidden
https://lists.gnu.org/mailman/listinfo/gnunet-developers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]