Preferred Way of Contributing Bug Fixes

44 views
Skip to first unread message

fleipold

unread,
Jan 2, 2012, 9:34:42 AM1/2/12
to Lift
Hi folks,

I have light-heartedly created two tickets around JSON parsing (1170
and 1171) (before reading the guidelines).
As these were production issues I did created fixes for the problem
that work for us.

What is the preferred way of contributing them back for review?

Best regards,
Felix Leipold

Todd O'Bryan

unread,
Jan 2, 2012, 11:19:50 AM1/2/12
to lif...@googlegroups.com
Unfortunately, Lift doesn't accept patches from non-committers. David
is (rightly) worried about intellectual property issues and wants
Lift's codebase to be as immune as possible from later challenges
regarding ownership.

That said, I've begun thinking over the past week or so that this
might be a weakness. One of the huge assets of open-source development
is that people can improve code. There have been a couple of times
when I've seen a problem and thought to myself, "I should really just
dig down into that, figure out what's going on, and see if I can make
it better." But then I remember that anything I come up with won't
make it into the codebase, and I just figure I'll work around it and
hope a committer comes up with a fix. Because the ratio of committers
to users is so small, I feel like tickets sit for longer in Lift than
they do in other projects. That may or may not be true, but it is my
perception.

I wonder if Lift might consider changing its policy on patches to
encourage people to post them so that others in the community who
aren't so worried about IP issues can benefit from them. Don't put
them into the project, so Lift's codebase remains pure, but at least
provide space for them to exist. In a way, contribution of patches
could be viewed as an application to become an official part of the
project. If someone posts enough patches, or a single patch that's so
useful to people that it demands to be pulled into the project proper,
then the person can be invited to sign the license agreement that
would make it possible to pull his/her code into the codebase. You
could even tell people that they shouldn't submit patches unless
they're willing to sign the Lift license agreement. Notice that you
don't have to make these people committers; once they've signed the
license agreement, a committer could apply their patches.

I realize this creates administrative overhead. Committers have to
review patches to find out who's worthy of inclusion, and someone has
to send out license agreements, make sure they get back, and archive
them. But I think the long-term advantages to the project would be
worth it. (Heck, I'll volunteer to be the administrative drone if that
helps.)

The final decision is obviously David's and if he thinks it's not
worth it, I respect that opinion. But I think there are tons of people
who will never be committers--they're just not visible enough on the
mailing lists and don't have the time to commit to Lift--who have
created improvements in the way Lift works that they'd be happy to
share with other people.

Todd

> --
> Lift, the simply functional web framework: http://liftweb.net
> Code: http://github.com/lift
> Discussion: http://groups.google.com/group/liftweb
> Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

David Pollak

unread,
Jan 3, 2012, 2:35:09 PM1/3/12
to lif...@googlegroups.com
Todd,

Part of the issue is IP cleanliness.  Another part of the issue is code and vision consistency.

Patches fall onto a spectrum of simple to complex.

There have been very few patches I've ever seen in Lift-land or elsewhere where the patch is on the simple end of the spectrum and the code is more valuable than the English description of the goal of the patch. 

Most of the complex patches require a deep understanding of how Lift works.  While in projects like Linux, you've got people who spend their days understanding the kernel and can submit complex patches, in Lift-land, it's generally easy to identify the folks who can create complex patches because they are part of the community and interact on the Lift list.

More importantly, non-trivial patches must be supported.  We've had some stuff added to Lift by fly-by committers (the Lift-JTA and Lift-Scaml integrations both come to mind.)  This kind of stuff has been a source of pain for those of us who stick around and support Lift because the code adds valuable features, but there's no-one to answer questions, no-one to update the modules when there's a new version of Scala, etc.

So, for simple patches, it's easier to get the feature discussed on the mailing list and have a ticket open and have one of the committers write the code.  For complex patches, it's better that the patch is handled by someone who will stand behind the code.

Now that I'm no longer the BDFL of Lift, but simply a committer among excellent committers, the policy may change.  Although, I will continue to advocate for having committers who have demonstrated that they are part of the community and will stick around.  There's an additional issue which is that there's no solid way to get new committers into committer-land.  Jan is the only new committer in quite a while and that's because I'm avoiding inviting folks to join the committers and part of my post-BDFL treading-lightly phase.  I'd love to see the rest of the committers identifying solid community members who have code to contribute so that we can invite them to commit.

Thanks,

David
--
Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro
Lift, the simply functional web framework http://liftweb.net
Reply all
Reply to author
Forward
0 new messages