From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: Re: none Date: Fri, 22 Jul 2016 10:15:38 +0200 Message-ID: <87k2gexf4l.fsf@gnu.org> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:55478) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bQVcF-0004Aq-QY for guix-devel@gnu.org; Fri, 22 Jul 2016 04:15:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bQVcD-0001Uf-GB for guix-devel@gnu.org; Fri, 22 Jul 2016 04:15:26 -0400 In-reply-to: <20160722004130.GA10340@thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins writes: > On Thu, Jul 21, 2016 at 02:51:38PM +0200, Ludovic Courtès wrote: >> In >> , >> you already identified exactly what we were going to say. :-) >> >> Namely, why are patches applied in a build phase rather than in >> ‘origin’, why is such and such test disabled (one sentence is usually >> enough), what happens if we set ‘HOME’ like Ben suggests, etc. >> >> What should we do? :-) > > I think I have covered that both in my writeup and in my response to > Ben. I think this work should be accepted as is. > > I think this is probably the last package I am contributing to main line. > Never liked dancing that much ;) For the last twenty weeks or so I have started contributing packages to GNU Guix mainly because Pjotr gave me the opportunity to do so. For me, upstreaming was part of the deal, and I'd say it has taken me at least two times the time it took me to write a proper package definition to get it in the upstream distribution. You've seen the mistakes I made, and the little syntactic things that kept going wrong over time. Near the end of my internship, however, I saw a positive change: Reviewers actually make little changes, instead of leaving it up to the submitter to ``fix the indendation''. This change makes the burden of reviewing smaller as well as the burden to submit a package. Great! One thing that really helped me in reducing the time to contribute changes to the upstream distribution, is to have a good workflow. I ended up doing the following: 1. Make the changes. 2. Commit the changes. 3 git format-patch -1 --no-attach 4. git reset --hard 5. Submit the patch to the mailing list 6. Wait for response and probably go back to 1. I made all of my changes on a GNU Guix git checkout. So, not writing package definitions on a separate repository. > But seriously, we should find other ways to encourage people. I wonder > how many packages are out there that never find their way into guix or > much too late. I wonder how much duplicate work is going on because of > our dance requirement. If it this hard *with* my experience in > packaging, how hard do you think it is for people *without* > experience. I know Dennis, for example, is sitting on a heap of opencl > packages which are incredibly useful to many people. > > I believe we have to change our ways. The problem is real. I have taken contributing back to upstream _very_ serious, and I haven't been able to get everything back into GNU Guix either. Packages I work(ed) on that haven't made it upstream (yet) due to ``imperfect'' patches: * MongoDB: Bundled source code; * GParted: The help function does not work without external documentation database tool; * FreeBayes: At first, licensing issues, now just a plain ugly patch to deal with the unbundling of its dependencies in the Makefiles of this project; * VCFLib: Same situation as FreeBayes. To be honest, this package would've not ended up as a separate package if I didn't have to split up FreeBayes. I consider this a positive effect of the review process. Lastly, I would like to say that I think the package reviews have always been positive and fair. We are trying to maintain a high-quality distribution, and this is a natural effect of trying to do so. Maybe we could create an online course to do packaging with GNU Guix and make it rewarding with a grading system and giving achievement points.. That might make the incentive to make the upstreaming step of packaging more fun and more like a learning process rather than a recurrent PITA. (This is something I could spend time at..) Kind regards, Roel Janssen