Re: Net-SNMP is moving to GitHub -- Your input appreciated

On Fri, May 11, 2018, at 1:59 AM, Josef Ridky wrote:
> Hi,
> 
> here are my 0.02$
> 
> | 
> | We have decided to move our Net-SNMP development to GitHub after many
> | wonderful years being hosted at SourceForge.  We greatly appreciate
> | SourceForge's support of open source projects over the years, but it's
> | time we take advantage of some features of GitHub that are unique and
> | should help us interact better with the community.  In particular, we
> | hope that GitHub's issues and pull system will allow us to more
> | flexibility in opening up development to more rapid integration by the
> | wider community.
> | 
> 
> Huge THANK YOU.
> 
> | * Things to consider
> | 
> |   1. code base
> |      - This is the easist task as git is decentralized.  The new
> |        codebase location is already up at:
> | 
> |      https://github.com/net-snmp/net-snmp
> | 
> |      One question about the code base is outstanding that we have not
> |      yet discussed enough to come to a conclusion about: whether we'll
> |      continue handling patches and forward pushes in the same way (IE,
> |      applying patches to the earliest supported branch and rolling
> |      them forward using merges).  Stay tuned, or better yet, offer
> |      your opinion.  Note that we've had great success with the merging
> |      mechanism as it has ensured us that no patch gets lost in an
> |      older version and that all patches are applied everywhere.  It's
> |      not the only way to do things though, but not losing patches
> |      while supporting older branches is an important feature
> |      consideration.

I would suggest following git accepted practice and go the other way around. New code goes to master branch first and the supported branch will only be used in cases that a "patch release" (i.e a 5.8.1) is needed.  If the log graph looks something like this:

master----|commit A|----|commit B|
  \
    supported_release----|commit C|----|commit D|

It should reduce the "merge..." commits since there's a better chance that merging from master to the  supported_release branch will be a fast-forward. This should also help keep push requests clean as there would be a better chance that the master branch of a fork of the net-snmp repo can easily fast-forward before they send in their push request.

In order for this to work well, I would suggest changing the release procedure/policy. We should focus on getting point releases out more often--say maybe once every 3 months at the extreme--and leaving patch releases to cases where a functionality inadvertently got broken and its now a complete show-stopper. If there's a workaround (short of maybe requiring a cronjob to restart snmpd every night) then they can wait for the next point release.

Distro/OS package managers, I'm going to turn the spotlight on you guys for a bit. What I would ask of you guys is let the Net-SNMP team know what Net-SNMP version you are providing for the OS version that you are supporting. Also, let the team know when that OS version has gone out of support. I feel it'll make it easier for the dev team to decide when to cut support for  a particular Net-SNMP version. I'm more than happy to generate and maintain this matrix for the Net-SNMP team once we start receiving this information.

> | 
> |   2. issues/bugs/patches
> | 
> |      This is one that we'd love feedback on.  Our choices are something
> |      along the lines of:
> | 
> |      a. start from scratch and don't move anything?
> |      b. start from bugs after a certain date, figuring the oldest are
> |      likely out of date
> |      c. see if someone has written a SF -> github issue mover
> 
> I am for option B. I think, that issues/bugs older than e.g. 5 years 
> could be omitted. 
> For patches, I think i will be better to go thru all of them, due 
> sometimes, there could be some useful idea that could help to improve 
> this project.

I'm for option A on this one. 5.8's pending release would put it 3 years after the 5.7.3 release. I we close off the bug tracker in SF, and new bugs are filed in github against 5.8.

I feel that options B and C will need to be tied together, and will require someone to go through and disposition what tickets will need to be moved.

> 
> | 
> |   3. website
> | 
> |      Move the primary website to netsnmp.github.io (with the
> |      http://www.net-snmp.org/ domain name continuing to work of course).
> | 
> 
> +1
> 
> |   4. wiki
> | 
> |      Our plan at this point is to convert wiki text to markdown so we
> |      can move it over to github.  This is currently being worked on and
> |      we expect it will be "mostly" successful.
> | 
> |   5. mailing lists
> | 
> |      This is one of the hardest topics.  We've used the SF based mailing
> |      lists for years and they've been one of the strongest aspects of
> |      the Net-SNMP community.  We may pick one of:
> | 
> |      a. Leave the mailing lists at SourceForge
> |      b. Host them elsewhere and have everyone manually move over after an
> |        announcement
> |      c. Switch to discussing things in issues only
> |      d. Switch to forums
> | 
> |      I'm not in favor of c or d, but I care more that the community's
> |      voice makes the decision.
> | 
> 
> Is it possible to keep the mailing list still available (don't have to 
> be at SF, but have somewhere a mailing list)?
> It is useful for general discussion and I think it is better than 
> forums.
> 
> |   6. downloads
> | 
> |      Github uses a different mechanism for distributing tarballs of
> |      downloads.  But I don't see an issue with this in the future.

For those that don't know the way github does releases is by creating a git tag. Once the tag is created, a "release" entry is created where a Net-SNMP core dev person can upload a package for users to download. Github itself will create a tarball of the raw source code if people want to go bare bones and run autotools on their own.

> | 
> |   7. Use of GitHub's extra features (builds, testing, CI type things)
> | 
> |      We will plan on making use of some of the extra goodies, of
> |      course.  But concentration will first be to move the pieces so
> |      we spend less energy being fragmented during the transition.
> | 
> | * Timeline
> | 
> |   1. The current 5.7.4 and 5.8 releases will be the last that we'll
> |      push to the SourceForge git repository and filesystem.
> |      Hopefully.

Can a 5.7.4 be avoided, that way bugs filed are focused on 5.8 only?

> | 
> |   2. The new git repo at github is already up and being updated.
> | 
> |   3. Future releases will be done from github
> | 
> |   4. New issues, etc, should be submitted to the GitHub issues tracker
> |      from now onward
> | 
> |   5. As major things are completed (IE, documentation moves), we'll
> |      make appropriate announcements
> | 
> | 
> | 
> | 
> | 
> | --
> | Wes Hardaker
> | Please mail all replies to [email protected]
> | 
> | ------------------------------------------------------------------------------
> | Check out the vibrant tech community on one of the world's most
> | engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> | _______________________________________________
> | Net-snmp-coders mailing list
> | [email protected]
> | https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
> | 
> 
> Once again, thanks a lot for your efforts!
> 
> Josef Ridky
> Associate Software Engineer
> Core Services Team
> Red Hat Czech, s.r.o.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Net-snmp-coders mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders


-- 
Thanks,
Keith (pantherse)

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot