[jcifs] Seven jCIFS bug fixes from Google./Future Development

[Michael B Allen]

On Thu, Jun 23, 2016 at 1:03 PM, Moritz Bechler <bechler at agno3.eu> wrote:
> Hi,
>
>>
>> That all sounds great but I would like to caution anyone forking JCIFS:
>>
>> I can see there are literally 5 pages of projects on github called
>> "jcifs". Not "jcifs-foo" or whatever but just "jcifs". If you or
>> anyone else creates a fork of jcifs, please do NOT call it "jcifs". If
>> someone builds it and makes a jcifs-x.x.x.jar they will not be able to
>> identify the fork from the original!
>
> Sure, totally agree, not changing the artifact name for mine was merely
> an oversight on my side.
>
> However the damage is already done with various other forks and as I
> said the I'm not too happy with the current state either.
>
> I guess these forks come for different reasons:
> - no public project infrastructure that people are now used to
> (repository, issue tracking, pull request, ...)
> - lack of artifacts (easily) usable in typical build processes
> - features (potentially also fixes) not integrated in mainline (or only
> as a patch)
> - general lack of visible activity
>
>
> Do you have any plans for future development? Would you be interested in
> being involved in an effort to address to above-mentioned issues and/or
> future-proofing the library?

Hi Moritz,

Can I make a recommendation?

Create a github project called jcifs-bugfix that is just the stock
jcifs with bug fixes. Do not change the behavior in any way. Do not
change the API. Do not add features. Maintain full 100% backward
compatibility. Just apply bugfixes. Make the README.md just state
clearly that it is the *stock* jcifs with minimal *bugfixes* applied
and that it is fully backward compatible with the original
corresponding version of jcifs.

If you do that and you resist the temptation to "make the code better"
and just do the minimum necessary to fix real problems and you
actually understand the protocol and the code enough so that your
fixes genuinely work (most patches submitted are not correct in some
way), then your project would have a chance of being successful.

And put the built jar in the top level directory where people can just
grab the jar and go. If someone has to git pull and build it, they
won't try it. Just make sure the jar is jcifs-bugfix-1.3.18.jar.
Please do not call it jcifs-1.3.18.jar.

But again, do not add or change anything. Just do "stock jcifs with
bug fixes". There are a lot of real business users who don't care
about development. SMB1 works just fine and it's not going away
anytime soon. They just want something that works so that they can get
on with their business and go home and play with their kids. If you
can be professional enough to provide a service like that, it will
reflect well on your project and people will use it.

This might all sound very boring but when everyone starts to use your
build it won't be boring because people will appreciate what you're
doing and we all just want to be loved right?

When you get some traction and people start following your project,
you can nudge them over to you're new code.

Mike

Disclaimer: I have not looked at your code and I don't know if you're
qualified to be doing any of this. I have to say that because I want
to make it clear to anyone who might read this that my statements are
not an endorsement of you're work. My recommendation is directed at
anyone who might be interested.