From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Allan Webber Subject: Re: none Date: Sun, 24 Jul 2016 11:52:52 -0500 Message-ID: <874m7fhtaz.fsf@dustycloud.org> References: <579027b7.VHXjhpPxQC3AAmeY%pjotr.public12@email> <8760rznoh1.fsf@gnu.org> <20160722004130.GA10340@thebird.nl> <20160722020656.GA10533@thebird.nl> <20160722110739.GA12722@thebird.nl> <20160722125014.GA13270@novena-choice-citizen> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35443) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bRMeQ-00072N-4f for guix-devel@gnu.org; Sun, 24 Jul 2016 12:53:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bRMeO-0008Ro-1M for guix-devel@gnu.org; Sun, 24 Jul 2016 12:53:13 -0400 In-reply-to: <20160722125014.GA13270@novena-choice-citizen> 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: Jookia <166291@gmail.com> Cc: guix-devel@gnu.org, Guix-devel Jookia writes: >> What makes things easier for me personally is to not worry about >> urgency. Nothing I do is really urgent. If I need to provide a packa= ge >> for someone at the institute I don=E2=80=99t wait for acceptance in Gu= ix >> upstream; I just push it to our own =E2=80=9Cguix-bimsb=E2=80=9D repo,= which is used via >> GUIX_PACKAGE_PATH. Eventually, changes are polished and get accepted >> upstream; at that point I remove them from the external repo. There i= s >> no hurry and I can choose to take my time addressing issues mentioned = in >> reviews. (One of my patches for =E2=80=9Cpam_limits=E2=80=9D went thr= ough several major >> revisions over a duration of half a year or so. I=E2=80=99m a sloth.) > > Guuix uses a mailing list for development, like most GNU projects. Mayb= e this > works for those, but Guix is trying to be hip and cool and fresh compar= ed to > most GNU projects which are stable and generally a pain to contribute t= o. > > On top of that, the maintainers can't even use the mailing list properl= y: > Patches are lost, discussion doesn't happen, things are lost and it's h= ard for > new users to join in. Who exactly benefits from this workflow compared = to > something web-based? Sure, maybe you could argue that the maintainers a= re best > served with it, or that you personally are attuned to that. Fine, but l= et's not > pretend the mailing list isn't gruelling. GNU MediaGoblin is "hip and cool" (or something) in that it uses a web based issue tracker primarily. (I guess it be hipper and cooler by using something that integrated with git and had "web based pull requests".) Note that it hasn't saved us here. There are times I fall behind, and so do other contributors, and things get clogged up. Often I am envious these days of the speed at which Guix moves. (A lot of the slowness is related to me trying to advance standards work that helps MediaGoblin in the long run, but that's an aside.) Technological decisions can play a huge part... though even more so is contributor bandwidth... >> Aren=E2=80=99t you already doing this with your separate package set o= n Github? >> In my opinion there is no need for an official project like that. We >> want most changes to be made to Guix directly. Changes there are much >> more likely to benefit the majority of users. > > This is the reason why I really dislike the current attitude of the com= munity. > You're building an operating system which by definition is meant to ser= ve a ton > of different needs, building it slowly and not urgently at all, but the= n arguing > changes should be kept centralized for the benefit of all users and sta= ging > features should be pushed to whateve personal repositories we have. Everyone else has said everything I'd like to say on this front mostly, but I *do* think it's great that Guix is pure and has high standards. That said, Guix probably could use some quasi-organized "guix-heresy" external repositories that help people be "practical" where we can't. (Heck, we won't be even able to advocate it, but the people who want it will find it.) To address Mark Weaver's points, yeah, that stuff will break occasionally as in terms of internal Guix changes to the codebase... that's the cost of doing it. As one more aside, I'm glad to see this conversation happening but also kind of bummed out... pretty much everyone on here I really admire. I'm confident things will pan out, if we listen to each other. - Chris