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

[Keith Mendoza]

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. 

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

[Wes Hardaker via Net-snmp-coders]

Josef Ridky  writes:

Thanks so much for your opinions!

|> 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.

Well, as my badly written options didn't explain well:

1) yes we can
2) if we move them, we have to start from scratch.  SourceForge made the
   decision awhile back to hide the users in the mailing list from
   everyone, including project administrators.  So the best we can do is
   post a "we're moving' note and hope everyone jumps.

And one of the questions is: where to keep the list?  I think a number
of us run systems that we could run it on, so that's not really an
issue.  But should we stay at SF so we don't people don't have to move.

-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net

--
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Wes Hardaker via Net-snmp-coders]

Stuart Henderson  writes:

|> One thing to note with this that's not immediately obvious with github
|> downloads, the automatically added "source code" links in github releases
|> are generated on-the-fly then cached, so they're subject to change if
|> they update software on nodes if the files expire from cache.

Yeah, and I've never liked the way github does downloads in general.
And we actually use a specially crafted tar to make sure it works on a
bunch of different systems with different tar requirements as well.

I suspect we'll still need to continue rolling our own downloads, so I
appreciate your note.
-- 
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net

--
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Stuart Henderson]

On 2018/05/10 16:14, Wes Hardaker via Net-snmp-coders wrote:
>   6. downloads
> 
>  Github uses a different mechanism for distributing tarballs of
>  downloads.  But I don't see an issue with this in the future.

One thing to note with this that's not immediately obvious with github
downloads, the automatically added "source code" links in github releases
are generated on-the-fly then cached, so they're subject to change if
they update software on nodes if the files expire from cache. If this
occurs it causes issues for distro packagers that check hashes, or for
anyone checking pgp signatures.

There's a way to upload an "asset" with a release on github allowing a
stable tar file to be uploaded and attached to it; rather than rewrite
one of my old list posts about this here's a link,
https://www.conserver.com/pipermail/users/2018-March/msg6.html

I wish github would document this better!


--
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

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

[Josef Ridky]

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.
| 
|   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.

| 
|   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.
| 
|   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.
| 
|   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 net-snmp-coders@lists.sourceforge.net
| 
| --
| 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
| Net-snmp-coders@lists.sourceforge.net
| 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 is moving to GitHub -- Your input appreciated

[Wes Hardaker via Net-snmp-coders]

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.

* 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.

  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

  3. website

 Move the primary website to netsnmp.github.io (with the
 http://www.net-snmp.org/ domain name continuing to work of course).

  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.

  6. downloads

 Github uses a different mechanism for distributing tarballs of
 downloads.  But I don't see an issue with this in the future.

  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.

  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 net-snmp-coders@lists.sourceforge.net

--
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
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders