I have a bunch of IRL stuff to deal with at the moment, and can't even work
on my own FOSS or proprietary code, so don't expect a "fork" soon.
When I say "broken", don't be offended, few codebases aren't broken in some
way :-)
One example of "broken" is my SCM url being munged from this:
scm:git:git:${project.groupId}/${project.artifactId}.git
To this:
scm:git:git:${project.groupId}/${project.artifactId}.git/${project.artifactId}
And all I have to say to that, other than the pain it caused me, is LOL!
:-p OK, I can add one more thing: F*** SVN. OK, now I'm done. :-)
Then there's the issue where my .ssh/config file was totally ignored unless
I used the external provider, and so on and so forth.
Reality check: It's a lot easier and quicker to hack in a fix for me that
breaks everyone else, than it is to agree on and implement a solution that
works for everyone in a backward compatible way. Hence fork. Make what I
need happen now and not sit around waiting for agreement on how to progress
"properly".
Other than a fork of my very own, I'd be VERY hesitant to trust anyone
else's forks. For example, I don't trust Debian Maven nor Fedora Maven out
of unjustified and paranoid fear that their patches to "just use what the
distro has" for deps might be active when they shouldn't be, etc. Forks
rarely gain traction, unless the base project is severely lacking in some
way.
Fred.
On Sat, Jul 27, 2013 at 9:56 AM, Hervé BOUTEMY <herve.bout...@free.fr>wrote:
> Le vendredi 26 juillet 2013 01:05:44 Fred Cooke a écrit :
> > About the fork, though, I'm interested. I'm interested in why it's
> > maintained and how it differs. I'm interested because I intend to fork it
> > myself to fix things which would break others which I know won't change
> > upstream (site and release stuff). Perhaps someone already fixed what I
> > consider broken and others, perhaps, do not consider broken. Email me
> > privately if need be.
> >
> > If the fork is just a branch (or set thereof), and not promoted as a fork
> > (in a social sense), then is there really any harm? Is it being viewed
> as a
> > loss of potential work done? Open source is open for a reason.
> +1
>
> in your case for example:
>
> if you make a fork to site plugin to fix it in a personal way, please don't
> hide it but show us where you fork/branch and explain how you change the
> code
> (in a Jira issue?): I'm interested to see your work and understand what
> you're
> doing, since I definitely don't understand how you find the plugin broken
> (and
> to be honest, every time I read this "broken" sentence, I feel aggressed).
>
> IMHO, a personal branch can be an excellent way of working with the
> community:
> I'm really interested to see you fix what I can't do because I really don't
> understand what is "broken".
>
> Of course, if the difference between your branch and trunk gets big, it'll
> be
> harder to find how to converge later: but we'll see. Explaned with the
> community from start, and used to interact with the community to show how
> it
> can evolve, we can understand and define with consensus that this can be a
> real
> friendly fork = a different choice on some fundamental point. Or perhaps it
> will be the start og m-site-p 4: who knows?
>
> Regards,
>
> Hervé
>
> >
> > Fred.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
