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
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
