I can set up gitlab if needed, but I'd prefer if someone put up a github instead.
In addition, the latest version is not 3.8 but 3.9.1 ke 12. heinäk. 2023 klo 6.04 Luis Felipe Strano Moraes ( luis.str...@gmail.com) kirjoitti: > Hey folks, bumping this old thread here, would be really nice to get a > release out there. If no one cares about being a maintainer, I can > definitely go ahead and do the work there to get the release out and keep > track of any other activities as time goes by, would be really good to not > have this bitrot completely. > > Best regards, > > > On Tue, Aug 30, 2022 at 8:24 PM Thien-Thi Nguyen <t...@gnuvola.org> wrote: > >> >> NB: To and Reply-To set to gnugo-devel m.l; Cc trimmed. >> >> () bump-m...@sporadic.stanford.edu (Daniel Bump (b...@math.stanford.edu >> email)) >> () Fri, 26 Aug 2022 06:44:28 -0700 >> >> > I hope that by including gnugo-devel in the discussion, we >> > can get more perspectives and that the GNU Go maintainers >> > can be convinced to change their position to that of "do >> > not keep generated files under version control", on the way >> > to eventually approving a merge of that branch and future >> > development along those lines. >> >> I think I was the one that was arguing for this position >> (mainly so that someone could build gnugo more easily after >> downloading from savannah versus a tarball), and since Gunnar >> was not in agreement, I would not insist on the point. >> >> That's great news. Thanks for reconsidering! I would like to >> propose the next steps for us to take, collectively: >> >> - create top-level file HACKING, includes info on >> - branch discipline (e.g., push to ‘master’ vs dev br & merge) >> - how to bootstrap (run autogen.sh, etc) >> - how to make a release >> - copyright discipline (e.g., once per year vs only on change) >> - coding conventions (whitespace, indentation, etc) >> - other developer-only info/lore >> - etc >> >> - merge branch ‘ttn-maint’ (and delete afterwards) >> >> - gather / apply other fixes found in the wild >> >> - make a test maintenance release (published on alpha.gnu.org) >> (info "(maintain) Test Releases") and solicit timely feedback >> >> - tweak as necessary / work out the kinks >> >> - make a "real" maintenance release >> >> I'm not a maintainer, but i can take a crack at writing HACKING >> (adapting the GNU RCS HACKING[1], basically, w/ input from >> everyone), and help out w/ the other stuff. It's been many >> years since the last GNU Go release, so there's no rush (IMHO), >> but i think it would be reasonable to aim for "real" release by >> end of year. >> >> What do the maintainers think? Is this something you'd approve? >> I don't want to step on anyone's toes! >> >> [1] http://git.savannah.gnu.org/cgit/rcs.git/tree/HACKING?h=p >> >> -- >> Thien-Thi Nguyen ----------------------------------------------- >> (defun responsep (query) ; (2022) Software Libero >> (pcase (context query) ; = Dissenso Etico >> (`(technical ,ml) (correctp ml)) >> ...)) 748E A0E8 1CB8 A748 9BFA >> --------------------------------------- 6CE4 6703 2224 4C80 7502 >> >> _______________________________________________ >> gnugo-devel mailing list >> gnugo-devel@gnu.org >> https://lists.gnu.org/mailman/listinfo/gnugo-devel >> > > > -- > Luís Felipe Strano Moraes > _______________________________________________ > gnugo-devel mailing list > gnugo-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/gnugo-devel >
_______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org https://lists.gnu.org/mailman/listinfo/gnugo-devel
