Re: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

That is a very useful list. What I would recommend though is we should finish 
dealing with the #ifdef hell and replacing autotools with cmake first. That way 
if we have to onboard new people to the project they are dealing with the 
"cleaned-up" code base.

On Sun, May 13, 2018, at 6:37 PM, Robert Story wrote:
> On Sun, 13 May 2018 18:15:16 -0700 Keith wrote:
> KM> On Sun, May 13, 2018, at 3:41 PM, Bart Van Assche wrote:
> KM> > Should a list of to-do items be added to the Net-SNMP wiki?  
> KM> 
> KM> I think a to-do wiki page on github would be a good idea to
> KM> deal with what needs to be done. Then, as each item is tackled
> KM> we should have a wiki page that details the requirement for
> KM> each list item. 
> 
> There is an ancient TODO list here:
> 
>   http://www.net-snmp.org/docs/TODO.html
> 
> Something in the wiki would probably be better, and we can redirect
> that static page to the wiki...
> 
> Robert


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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Robert Story]

On Sun, 13 May 2018 18:15:16 -0700 Keith wrote:
KM> On Sun, May 13, 2018, at 3:41 PM, Bart Van Assche wrote:
KM> > Should a list of to-do items be added to the Net-SNMP wiki?  
KM> 
KM> I think a to-do wiki page on github would be a good idea to
KM> deal with what needs to be done. Then, as each item is tackled
KM> we should have a wiki page that details the requirement for
KM> each list item. 

There is an ancient TODO list here:

  http://www.net-snmp.org/docs/TODO.html

Something in the wiki would probably be better, and we can redirect
that static page to the wiki...

Robert

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Sun, May 13, 2018, at 3:41 PM, Bart Van Assche wrote:
> On 04/12/18 08:31, Ian Bruene wrote:
> > This morning we (Keith, Ian) met with an assortment of the NET-SNMP 
> > developers / contributors (primarily Bart Van Assche) to discuss how we 
> > could best help the project. The meeting went well, at least form our 
> > perspective.
> > 
> > The pain points we identified were:
> > 
> > * bug mountain
> > 
> > * help users on the mailing list
> > 
> > * patch / MR handling process
> > 
> > * move out of SourceForge
> > 
> > * clean up headers in /include/net-snmp/system/ which are a mess and 
> > have import loops
> > 
> > * #ifdef hell / too many supported configurations
> > 
> > Keith is currently focused on streamlining the process of handling merge 
> > requests, which will make it easier to handle the bug mountain. I will 
> > probably be focusing on the headers for now in hopes that it will make 
> > other processes easier as well. We can help on the repo move whenever 
> > y'all are ready to pull the trigger on that.
> 
> Should a list of to-do items be added to the Net-SNMP wiki?

I think a to-do wiki page on github would be a good idea to deal with what 
needs to be done. Then, as each item is tackled we should have a wiki page that 
details the requirement for each list item. 

> 
> Also, how about adding the following item to the above list: getting rid 
> of 'makedepend' for generating dependency files. Makedepend is 
> considered deprecated and does not work properly on modern systems. Any 
> build system that supports dependency generation is a possible 
> alternative (automake, cmake, ...). See also 
> https://en.wikipedia.org/wiki/Makedepend and 
> https://bugs.freedesktop.org/show_bug.cgi?id=10021.

I think this can be dealt with as part of migrating from autotools to cmake. I 
would also suggest looking into rolling in the #ifdef hell; as cmake can be 
used to deal with the things that #ifdef is dealing with.
 
> 
> Bart.
> 
> --
> 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


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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Bart Van Assche]

On 04/12/18 08:31, Ian Bruene wrote:
This morning we (Keith, Ian) met with an assortment of the NET-SNMP 
developers / contributors (primarily Bart Van Assche) to discuss how we 
could best help the project. The meeting went well, at least form our 
perspective.


The pain points we identified were:

* bug mountain

* help users on the mailing list

* patch / MR handling process

* move out of SourceForge

* clean up headers in /include/net-snmp/system/ which are a mess and 
have import loops


* #ifdef hell / too many supported configurations

Keith is currently focused on streamlining the process of handling merge 
requests, which will make it easier to handle the bug mountain. I will 
probably be focusing on the headers for now in hopes that it will make 
other processes easier as well. We can help on the repo move whenever 
y'all are ready to pull the trigger on that.


Should a list of to-do items be added to the Net-SNMP wiki?

Also, how about adding the following item to the above list: getting rid 
of 'makedepend' for generating dependency files. Makedepend is 
considered deprecated and does not work properly on modern systems. Any 
build system that supports dependency generation is a possible 
alternative (automake, cmake, ...). See also 
https://en.wikipedia.org/wiki/Makedepend and 
https://bugs.freedesktop.org/show_bug.cgi?id=10021.


Bart.

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

Wes,

On Thu, May 10, 2018, at 4:12 PM, Wes Hardaker wrote:
> Keith Mendoza  writes:
> 
> > I would very much like to be part of the discussion regarding moving
> > to Github if its amenable to you guys.
> 
> Sorry for the delay on this; I had a week and a half of constant special
> meetings that took me away from mail.

I appreciate you getting back to this conversation. I sent my 
suggestions/thoughts regarding the github move to the appropriate thread. I'm 
very excited for the new season of Net-SNMP.

> 
> I'm going to post an announcement to -coders here in a few minutes with
> the status and it will ask for feedback.  Please feel free to give
> opinions!
> 
> > In my opinion a discussion forum is the best alternative to a mailing
> > list system.
> 
> Yeah, and that's where we can't please everyone.  I absolutely
> (personally) hate forum systems.  They're not threaded (sometimes to 1
> level), hard to track, hard to tell what's new, hard to catch up on,
> etc.

I agree that we can't please everyone. I think we'll just have to put it to the 
community for a vote should SF give the mailing list hte pink slip.

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


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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Wes Hardaker via Net-snmp-coders]

Keith Mendoza  writes:

> I would very much like to be part of the discussion regarding moving
> to Github if its amenable to you guys.

Sorry for the delay on this; I had a week and a half of constant special
meetings that took me away from mail.

I'm going to post an announcement to -coders here in a few minutes with
the status and it will ask for feedback.  Please feel free to give
opinions!

> In my opinion a discussion forum is the best alternative to a mailing
> list system.

Yeah, and that's where we can't please everyone.  I absolutely
(personally) hate forum systems.  They're not threaded (sometimes to 1
level), hard to track, hard to tell what's new, hard to catch up on,
etc.

-- 
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Fri, Apr 27, 2018, at 7:53 PM, Wes Hardaker wrote:
> Robert Story  writes:
> 
> |> That discussion is going on over on our admin list. It's not just a
> |> few of us running amok. ;-)

First, I meant no disrespect when I said "I think it would be best to get full 
agreement from the team on this." My apologies if my statement came across that 
way. 

> 
> Specifically, there are a bunch of pieces that we're considering
> individually.  We'll definitely move the repository, we're definitely
> going to start sending new issues over there.  There is debate about
> what to do with the old issues...  Many are out of date.  Bill Fenner is
> looking into converting the wiki pages to markdown.  etc...  We don't
> have an alternative to the SF mailing lists, though hosting them could
> be done in an number of places but email lists isn't really the way of
> github.  For now we'll leave them on sourceforge.  But under sourceforge
> we can no longer extract all the email addresses to move them, so it'll
> require manual process by everyone subscribed if we do move them.  We'd
> be happy to hear about any other thoughts you have about other
> considerations.  We are deliberately waiting until after 5.8 gets out
> the door to move anything, but our 5.8 announcement will include text
> about the upcoming changes.

I would very much like to be part of the discussion regarding moving to Github 
if its amenable to you guys. As for the old issues, Ian and I suggested 
closing/dropping bugs created before 2012 Nov 8 mainly because of the bug's age 
and the modify on those seem to be a side effect of possibly some activity from 
Sourceforge's infrastructure.

I'm personally split about what should be done the mailing lists. I find it 
convenient because it's email that lands in your inbox with your other emails. 
But, I feel figure out where the conversation has gone so far may require going 
to the mailing list archive a disadvantage. In my opinion a discussion forum is 
the best alternative to a mailing list system. Unfortunately, GIthub doesn't 
have a "discussion forum" system, and users have been begging for it (see 
https://github.com/dear-github/dear-github/issues/44 but I won't hold my breath 
on this one).

What I would add to the list is having a discussion on the following and target 
having a process in place before the "grand opening" to Github:
* "issues" that would normally go on a "discussion forum" if Github had one.
* Whether to stay with the current process of applying changes in the current 
release branch and master.
* How merge requests will be processed.

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


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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Wes Hardaker via Net-snmp-coders]

Robert Story  writes:

|> That discussion is going on over on our admin list. It's not just a
|> few of us running amok. ;-)

Specifically, there are a bunch of pieces that we're considering
individually.  We'll definitely move the repository, we're definitely
going to start sending new issues over there.  There is debate about
what to do with the old issues...  Many are out of date.  Bill Fenner is
looking into converting the wiki pages to markdown.  etc...  We don't
have an alternative to the SF mailing lists, though hosting them could
be done in an number of places but email lists isn't really the way of
github.  For now we'll leave them on sourceforge.  But under sourceforge
we can no longer extract all the email addresses to move them, so it'll
require manual process by everyone subscribed if we do move them.  We'd
be happy to hear about any other thoughts you have about other
considerations.  We are deliberately waiting until after 5.8 gets out
the door to move anything, but our 5.8 announcement will include text
about the upcoming changes.

-- 
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: Summary of meeting between NET-SNMP devs and ICEI

[Robert Story]

On Wed, 25 Apr 2018 13:24:12 -0700 Keith wrote:
KM> On Wed, Apr 25, 2018, at 12:08 PM, Robert Story wrote:
KM> > We've had recent discussions on this, and I think we'll be
KM> > moving the source to github in the near future.  
KM> 
KM> I think it would be best to get full agreement from the team on
KM> this. I hear bits-and-pieces that there have been some move in
KM> that direction. However, I think there should be a separate
KM> discussion just on that topic and what it would entail to
KM> officially move the Net-SNMP project over.

That discussion is going on over on our admin list. It's not just a
few of us running amok. ;-)

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Steve Friedl]

Wow, these are names from the past; I find it hard to believe there is any
legitimate need to support these going forward.

Steve - who's ported to almost all of those platforms

-Original Message-
From: Eric S. Raymond [mailto:e...@thyrsus.com] 
Sent: Wednesday, April 25, 2018 8:25 PM
To: Bart Van Assche <bvanass...@acm.org>
Cc: Susan Sons <su...@icei.org>; net-snmp-coders@lists.sourceforge.net;
Robert Story <rst...@freesnmp.com>
Subject: Re: Summary of meeting between NET-SNMP devs and ICEI

Bart Van Assche <bvanass...@acm.org>:
> Which of the following files under include/net-snmp/system do you 
> think are still relevant today? No changes other than trivial changes 
> have been made to these files in the past ten years:
> 
> dynix.h irix.h osf5.h svr5.h ultrix.h

LOL. I've seen this movie before.  It's very common in codebases of this age
and size range.

Nuke them from orbit, sez I.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute:
https://icei.org Please visit their site and donate: the civilization you
save might be your own.




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


--
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: Summary of meeting between NET-SNMP devs and ICEI

[Eric S. Raymond]

Bart Van Assche :
> Which of the following files under include/net-snmp/system do you think are
> still relevant today? No changes other than trivial changes have been made
> to these files in the past ten years:
> 
> dynix.h irix.h osf5.h svr5.h ultrix.h

LOL. I've seen this movie before.  It's very common in codebases of this
age and size range.

Nuke them from orbit, sez I.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
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: Summary of meeting between NET-SNMP devs and ICEI

[Bart Van Assche]

On 04/25/18 13:08, Robert Story wrote:

IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB>
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.


Hello Robert,

Which of the following files under include/net-snmp/system do you think 
are still relevant today? No changes other than trivial changes have 
been made to these files in the past ten years:


dynix.h irix.h osf5.h svr5.h ultrix.h

Thanks,

Bart.

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Eric S. Raymond]

Robert Story :
>And as far as supported configurations, we're
> very big on backwards compatibility.

I think you are spending more effort on this than field conditions justify.
And there is a cost you probably have not audited.

I learned my Unix programming chops back in the 1980s when having thickets
of portability #ifdefs was definitely the right thing to do because there
was so much variation in platform APIs. I too acquired the reflex of never
throwing any of those out, just in case

This attitude has been obsolete for at least 9 years.

The reason I'm that precise about it is because of a learning
experience I had while maintaining GPSD in 2009. The important fact
about GPSD in this context is that it is deployed on a *huge* breadth
of hardware, not just datacenter machines but laptops and smartphones
and embedded gear of all sorts.

Came the day I was doing some routine cleanup, I tripped over a port
#ifdef for a species of big-iron Unix that will never again walk the
earth, and the following thought intruded: "What? Is this really needed?"

Slightly amazed at my own heresy, I continued to think "You know, this
is a build variant I can no longer test.  Why am I letting it clutter
up my code and complicate my build recipe?"

*blink*

Because I have a reflex about these things. I screen out their complexity
cost by habit.

So I went on an #ifdef hunt.  I had never really totaled up the number of
LOC added by alternate build options before.  It was significant.

My next step was to ask how I could reduce this.  The obvious thing to
try was to assume that the standards people won the war - anywhere I
found an #ifdef where one of the paths assumed SuSv2+C99 and rip out
all the other paths.

When I did that, the resulting patch was large but obviously reversible.
So I tried the bold thing.  I removed all that code and shipped a point release.

My reasoning was thus: point releases are cheap.  This change, if it's
bad, will throw an error at compile time well before it disrupts any
runtime behavior.  I can put back the pieces I actually need when the
build failures hit my bugtracker.

I never saw even one.

And that's how I learned that the standards people had succeeded.

Six years later I preformed a similar cruftectomy on the NTP code.
Again, never a peep of complaint from anyone downstream.

The benefits: (1) fewer LOC of more readable code, (2) fewer test paths,
(3) simpler build recipe.

> As 5.8 is getting really close to going out the door, this type of
> cleanup likely won't make it into that release.
> 
> 
> Got any cmake experts? One of the planned items for 5.9 is moving
> to cmake. The bulk of the work is done (patches from VMware against
> 5.7), but work will be needed to integrate to master and put on the
> finishing touches.

I occasionally used cmake when I was on the Battle for Wesnoth project.

I don't like it.  Not so much because cmake is bad in itself, it isn't.
It's a reasonable implementation of its design premises.

The problem is that one of cmake's premises is being a two-phase builder,
generating makefiles, rather than a one-phase builder that directly executes
its recipe.  This repeats the autoconf tragedy, making buld-failure
diagnosis *far* more complex and gnarly than it needs to be.

I have come to believe that all two-phase build engines should be shot
with silver bullets and buried at crossroads with stakes through
their hearts.
-- 
http://www.catb.org/~esr/;>Eric S. Raymond

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.



--
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Wed, Apr 25, 2018, at 12:08 PM, Robert Story wrote:
> On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
> IB> This morning we (Keith, Ian) met with an assortment of the
> IB> NET-SNMP developers / contributors (primarily Bart Van Assche)
> IB> to discuss how we could best help the project. The meeting went
> IB> well, at least form our perspective.
> 
> I'm sorry I missed this meeting. I'm almost always on IRC, but
> sometimes go a while without checking the mailing list.
> 
> IB> The pain points we identified were:
> IB> 
> IB> * bug mountain
> IB> * help users on the mailing list
> IB> * patch / MR handling process
> 
> Yep, those are biggies.
> 
> IB> * move out of SourceForge
> 
> We've had recent discussions on this, and I think we'll be moving
> the source to github in the near future.

I think it would be best to get full agreement from the team on this. I hear 
bits-and-pieces that there have been some move in that direction. However, I 
think there should be a separate discussion just on that topic and what it 
would entail to officially move the Net-SNMP project over.

> 
> IB> * clean up headers in /include/net-snmp/system/ which are a
> IB> mess and have import loops
> IB> 
> IB> * #ifdef hell / too many supported configurations
> 
> I'm a little nervous about these one, especially with folks that are
> new to the code base. And as far as supported configurations, we're
> very big on backwards compatibility.
> 
> As 5.8 is getting really close to going out the door, this type of
> cleanup likely won't make it into that release.

Agree completely on both points. I feel that this project should be done by a 
group that's composed by those who know the code, and those new to the code. 
That way, we have assurance that things are not being dropped on the floor on 
accident and that a good knowledge transfer happens. I would go so far as to 
suggest that one member of this "team" should be tasked with documenting what's 
going on; essentially appoint a project librarian if you will.

One conversation I was a part of regarding the configuration is to modularize 
things better and leverage the build system to decide what source files will be 
included in the build based on the target system/configuration. I personally 
would suggest holding this off until we've moved to github.
 
> 
> 
> Got any cmake experts? One of the planned items for 5.9 is moving
> to cmake. The bulk of the work is done (patches from VMware against
> 5.7), but work will be needed to integrate to master and put on the
> finishing touches.

I have experience using cmake, and I'm sure I can tap other people if need be. 
I would suggest that we look into whether the cmake move should be part of the 
"#ifdef hell..." clean up. If you can point me to the branch where the 
CMake-related files are currently stored I'll do some research on it once 5.8 
is released.

As far as versioning is concerned; I personally feel if the build system is 
switched to cmake that it should be considered a major release. I feel that 
rolling it to 5.9 may give some package managers a nasty surprise when their 
packaging script suddenly starts breaking.

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

There are obviously a lot of irons that are suddenly being considered to be 
thrown in the fire. Would the Net-SNMP team be amenable to either a 
conference/meeting either on IRC, phone, or video chat to develop a long-term 
plan for the project? I have access to systems we can use for a phone or video 
conference.

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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Ian Bruene]

On 04/25/2018 02:08 PM, Robert Story wrote:

On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB>
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.

As 5.8 is getting really close to going out the door, this type of
cleanup likely won't make it into that release.


Understandable. Keith has been focusing on the patching and release 
process. I've had to take a back seat as another project I'm on is 
currently in pre-deadline crunch.

Got any cmake experts? One of the planned items for 5.9 is moving
to cmake. The bulk of the work is done (patches from VMware against
5.7), but work will be needed to integrate to master and put on the
finishing touches.

Robert


I think we do.

--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


I work for the Internet Civil Engineering Institute , 
help us save the Internet from Entropy!


--
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: Summary of meeting between NET-SNMP devs and ICEI

[Robert Story]

On Thu, 12 Apr 2018 10:31:13 -0500 Ian wrote:
IB> This morning we (Keith, Ian) met with an assortment of the
IB> NET-SNMP developers / contributors (primarily Bart Van Assche)
IB> to discuss how we could best help the project. The meeting went
IB> well, at least form our perspective.

I'm sorry I missed this meeting. I'm almost always on IRC, but
sometimes go a while without checking the mailing list.

IB> The pain points we identified were:
IB> 
IB> * bug mountain
IB> * help users on the mailing list
IB> * patch / MR handling process

Yep, those are biggies.

IB> * move out of SourceForge

We've had recent discussions on this, and I think we'll be moving
the source to github in the near future.

IB> * clean up headers in /include/net-snmp/system/ which are a
IB> mess and have import loops
IB> 
IB> * #ifdef hell / too many supported configurations

I'm a little nervous about these one, especially with folks that are
new to the code base. And as far as supported configurations, we're
very big on backwards compatibility.

As 5.8 is getting really close to going out the door, this type of
cleanup likely won't make it into that release.


Got any cmake experts? One of the planned items for 5.9 is moving
to cmake. The bulk of the work is done (patches from VMware against
5.7), but work will be needed to integrate to master and put on the
finishing touches.

Robert

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Thu, Apr 12, 2018, at 2:18 PM, Magnus Fromreide wrote:
> On Thu, Apr 12, 2018 at 12:19:35PM -0700, Keith Mendoza wrote:
> > On Thu, Apr 12, 2018, at 10:03 AM, Bill Fenner wrote:
> > > I'm sorry that I wasn't available for this meeting.  I think one important
> > > pain point is the overhead of doing releases - 5.7.3 was years ago and
> > > there are very useful fixes in the 5.7 branch; why can't we just say 
> > > "now's
> > > a good time for 5.7.4 and if we don't get it right then we can release
> > > 5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
> > > know what's involved.
> > 
> > I think from a project morale perspective it will be good to get a 5.7.4 
> > out. > At the very least, it'll show the world that the project is active 
> > (or active
> > again if they choose to see it that way). Is there a working list of what
> > bugs/features are planned for 5.7.4; if so, can that be finalized at this
> > point?
> 
> I think 5.7.4 is just a bugfix release.
> 5.8, of which I think the release process was initiated a while back, is
> a new feature release. I know that I have added a typed value to the perl
> handlers so that you won't have to change a global parameter in the agent to
> get hold of the numeric oid value of an oid-type variable.

I'll go ahead and look through the bugs that are in "Pending" state and compile 
a list of ones that have an indication that it has fixes ready for a  5.7.4. 
When I'm done, I'll send the list in a separate thread; hopefully, that 
provides some visibility of what a 5.4.7 might look like.

> 
> /MF
> 
> > > 
> > >   Bill
> > > 
> > > 
> > > On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene  wrote:
> > > 
> > > >
> > > > This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> > > > developers / contributors (primarily Bart Van Assche) to discuss how we
> > > > could best help the project. The meeting went well, at least form our
> > > > perspective.
> > > >
> > > > The pain points we identified were:
> > > >
> > > > * bug mountain
> > > >
> > > > * help users on the mailing list
> > > >
> > > > * patch / MR handling process
> > > >
> > > > * move out of SourceForge
> > 
> > If a release of 5.7.4 is done in the next month or so, that might also be a 
> > good time to put up the "we're moving" sign. If we can get a few people 
> > whose done this before to get together, coming up with the plan could be 
> > done in parallel with the 5.7.4 work. 
> > 
> > > >
> > > > * clean up headers in /include/net-snmp/system/ which are a mess and 
> > > > have
> > > > import loops
> > > >
> > > > * #ifdef hell / too many supported configurations
> > > >
> > > > Keith is currently focused on streamlining the process of handling merge
> > > > requests, which will make it easier to handle the bug mountain. I will
> > > > probably be focusing on the headers for now in hopes that it will make
> > > > other processes easier as well. We can help on the repo move whenever 
> > > > y'all
> > > > are ready to pull the trigger on that.
> > 
> > I have a few questions for the core team regarding this; expect another 
> > email to the mailing list in a little bit.
> > 

=== snip 

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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Magnus Fromreide]

On Thu, Apr 12, 2018 at 12:19:35PM -0700, Keith Mendoza wrote:
> On Thu, Apr 12, 2018, at 10:03 AM, Bill Fenner wrote:
> > I'm sorry that I wasn't available for this meeting.  I think one important
> > pain point is the overhead of doing releases - 5.7.3 was years ago and
> > there are very useful fixes in the 5.7 branch; why can't we just say "now's
> > a good time for 5.7.4 and if we don't get it right then we can release
> > 5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
> > know what's involved.
> 
> I think from a project morale perspective it will be good to get a 5.7.4 out. 
> > At the very least, it'll show the world that the project is active (or 
> active
> again if they choose to see it that way). Is there a working list of what
> bugs/features are planned for 5.7.4; if so, can that be finalized at this
> point?

I think 5.7.4 is just a bugfix release.
5.8, of which I think the release process was initiated a while back, is
a new feature release. I know that I have added a typed value to the perl
handlers so that you won't have to change a global parameter in the agent to
get hold of the numeric oid value of an oid-type variable.

/MF

> > 
> >   Bill
> > 
> > 
> > On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene  wrote:
> > 
> > >
> > > This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> > > developers / contributors (primarily Bart Van Assche) to discuss how we
> > > could best help the project. The meeting went well, at least form our
> > > perspective.
> > >
> > > The pain points we identified were:
> > >
> > > * bug mountain
> > >
> > > * help users on the mailing list
> > >
> > > * patch / MR handling process
> > >
> > > * move out of SourceForge
> 
> If a release of 5.7.4 is done in the next month or so, that might also be a 
> good time to put up the "we're moving" sign. If we can get a few people whose 
> done this before to get together, coming up with the plan could be done in 
> parallel with the 5.7.4 work. 
> 
> > >
> > > * clean up headers in /include/net-snmp/system/ which are a mess and have
> > > import loops
> > >
> > > * #ifdef hell / too many supported configurations
> > >
> > > Keith is currently focused on streamlining the process of handling merge
> > > requests, which will make it easier to handle the bug mountain. I will
> > > probably be focusing on the headers for now in hopes that it will make
> > > other processes easier as well. We can help on the repo move whenever 
> > > y'all
> > > are ready to pull the trigger on that.
> 
> I have a few questions for the core team regarding this; expect another email 
> to the mailing list in a little bit.
> 
> > >
> > > --
> > > *"In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> > > Chooses, a Slave Obeys."* -- Andrew Ryan
> > >
> > > *"Utopia cannot precede the Utopian. It will exist the moment we are fit
> > > to occupy it."* -- Sophia Lamb
> > >
> > > I work for the Internet Civil Engineering Institute ,
> > > help us save the Internet from Entropy!
> > >
> > > 
> > > --
> > > 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
> > >
> > >
> > --
> > 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
> 
> 
> -- 
> 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
> Net-snmp-coders@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/net-snmp-coders

--
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: Summary of meeting between NET-SNMP devs and ICEI

[Keith Mendoza]

On Thu, Apr 12, 2018, at 10:03 AM, Bill Fenner wrote:
> I'm sorry that I wasn't available for this meeting.  I think one important
> pain point is the overhead of doing releases - 5.7.3 was years ago and
> there are very useful fixes in the 5.7 branch; why can't we just say "now's
> a good time for 5.7.4 and if we don't get it right then we can release
> 5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
> know what's involved.

I think from a project morale perspective it will be good to get a 5.7.4 out. 
At the very least, it'll show the world that the project is active (or active 
again if they choose to see it that way). Is there a working list of what 
bugs/features are planned for 5.7.4; if so, can that be finalized at this point?

> 
>   Bill
> 
> 
> On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene  wrote:
> 
> >
> > This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> > developers / contributors (primarily Bart Van Assche) to discuss how we
> > could best help the project. The meeting went well, at least form our
> > perspective.
> >
> > The pain points we identified were:
> >
> > * bug mountain
> >
> > * help users on the mailing list
> >
> > * patch / MR handling process
> >
> > * move out of SourceForge

If a release of 5.7.4 is done in the next month or so, that might also be a 
good time to put up the "we're moving" sign. If we can get a few people whose 
done this before to get together, coming up with the plan could be done in 
parallel with the 5.7.4 work. 

> >
> > * clean up headers in /include/net-snmp/system/ which are a mess and have
> > import loops
> >
> > * #ifdef hell / too many supported configurations
> >
> > Keith is currently focused on streamlining the process of handling merge
> > requests, which will make it easier to handle the bug mountain. I will
> > probably be focusing on the headers for now in hopes that it will make
> > other processes easier as well. We can help on the repo move whenever y'all
> > are ready to pull the trigger on that.

I have a few questions for the core team regarding this; expect another email 
to the mailing list in a little bit.

> >
> > --
> > *"In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> > Chooses, a Slave Obeys."* -- Andrew Ryan
> >
> > *"Utopia cannot precede the Utopian. It will exist the moment we are fit
> > to occupy it."* -- Sophia Lamb
> >
> > I work for the Internet Civil Engineering Institute ,
> > help us save the Internet from Entropy!
> >
> > 
> > --
> > 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
> >
> >
> --
> 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


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

Re: Summary of meeting between NET-SNMP devs and ICEI

[Bill Fenner]

I'm sorry that I wasn't available for this meeting.  I think one important
pain point is the overhead of doing releases - 5.7.3 was years ago and
there are very useful fixes in the 5.7 branch; why can't we just say "now's
a good time for 5.7.4 and if we don't get it right then we can release
5.7.5 soon"?  To be fair, I've never driven a net-snmp release so I don't
know what's involved.

  Bill


On Thu, Apr 12, 2018 at 11:31 AM, Ian Bruene  wrote:

>
> This morning we (Keith, Ian) met with an assortment of the NET-SNMP
> developers / contributors (primarily Bart Van Assche) to discuss how we
> could best help the project. The meeting went well, at least form our
> perspective.
>
> The pain points we identified were:
>
> * bug mountain
>
> * help users on the mailing list
>
> * patch / MR handling process
>
> * move out of SourceForge
>
> * clean up headers in /include/net-snmp/system/ which are a mess and have
> import loops
>
> * #ifdef hell / too many supported configurations
>
> Keith is currently focused on streamlining the process of handling merge
> requests, which will make it easier to handle the bug mountain. I will
> probably be focusing on the headers for now in hopes that it will make
> other processes easier as well. We can help on the repo move whenever y'all
> are ready to pull the trigger on that.
>
> --
> *"In the end; what separates a Man, from a Slave? Money? Power? No. A Man
> Chooses, a Slave Obeys."* -- Andrew Ryan
>
> *"Utopia cannot precede the Utopian. It will exist the moment we are fit
> to occupy it."* -- Sophia Lamb
>
> I work for the Internet Civil Engineering Institute ,
> help us save the Internet from Entropy!
>
> 
> --
> 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
>
>
--
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

Summary of meeting between NET-SNMP devs and ICEI

[Ian Bruene]

This morning we (Keith, Ian) met with an assortment of the NET-SNMP 
developers / contributors (primarily Bart Van Assche) to discuss how we 
could best help the project. The meeting went well, at least form our 
perspective.


The pain points we identified were:

* bug mountain

* help users on the mailing list

* patch / MR handling process

* move out of SourceForge

* clean up headers in /include/net-snmp/system/ which are a mess and 
have import loops


* #ifdef hell / too many supported configurations

Keith is currently focused on streamlining the process of handling merge 
requests, which will make it easier to handle the bug mountain. I will 
probably be focusing on the headers for now in hopes that it will make 
other processes easier as well. We can help on the repo move whenever 
y'all are ready to pull the trigger on that.


--
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan


/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb


I work for the Internet Civil Engineering Institute , 
help us save the Internet from Entropy!


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