Re: [gnugo-devel] Membership request for group GNU Go

[Stefan Pejovski]

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.strano@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 <ttn@gnuvola.org> wrote:

NB: To and Reply-To set to gnugo-devel m.l; Cc trimmed.

() bump-math@sporadic.stanford.edu (Daniel Bump (bump@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