From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23372 invoked by alias); 1 Nov 2017 22:59:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 41972 Received: (qmail 720 invoked by uid 1010); 1 Nov 2017 22:59:26 -0000 X-Qmail-Scanner-Diagnostics: from park01.gkg.net by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(205.235.26.22):SA:0(-1.7/5.0):. Processed in 1.112 secs); 01 Nov 2017 22:59:26 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, RP_MATCHES_RCVD,SPF_PASS,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.1 X-Envelope-From: SRS0=Krkr=B7=yahoo.co.uk=okiddle@bounces.park01.gkg.net X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | X-Virus-Scanned: by amavisd-new at gkg.net Authentication-Results: amavisd4.gkg.net (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1509577135; bh=NMNZB/u3ihkM1vbla1wtWmE5n3JTi30HDjS7V/h+ZXU=; h=From:References:To:Subject:Date:From:Subject; b=Fi7/4jkhwgoZZ5wKL/4sac8h3Fq9EmRpWTSMvjCndnDv7Dy6K0JLUYYABsuvH9sRtk+xSOMVbsOaNta4NQbrFaBdtwUmcqlF2b3WDXo3sxzp9wWpeu2qqhxqRISnERmya7SWz7uKswTSYP3vax2HRjAQ1k+VmOPwnhmz1kYmhs+9Jm7eqjfqP5W4SqiW8ydkJHg94GVtVwv3Ba6r4j0Lpfmt9uSnwX88o5Pik0gGfCtF9xypDZWQ1sdghAIA5RxuEJKKrjp72DKksoF44CQLa0/tPA8WuETIla0lWPeSdoQjbmEHCDW+yJoFGDVh2dnuL1m7J1IBKTL341rZ8DP+YQ== X-YMail-OSG: B2Kax9MVM1md39W0oy_RJG6T5mvgLFqgunxH6tW51fDWeSubzzu__CQ9BCwr4t3 F2TsinLBIKGQHcbcwXpdIcQBk89WWZoVtbyHptFtCS0AYPlSD5hXnu4m_.dhqRbQLhwL0XW1qYSh 8psebsQQJS.11bKYb27L2DPDs_nzPxAoi5VpVauNEyGzh1wbmEas7Y0i43gOBDKvKx893054MpDe G4vpiHuGtk6b44SN2H6SR_QY.t_eBu.FiOPw0NACIDjDwPnDcVDcMXnyK60A17ogw9Y1a719LL.f VVgKayHd7HlhyOiJPsTA1AFhFP8Iog5MYTRwScyJ5f_6zbqNzI0d05G70dqXZjofP5b5b_2E.8V3 xh4dOZstL7vUKAfBc4IEm33egS8AZ98Ibs686dM_H5ggyFWy7JV3DJr7wB1uOc8CJeWq0IX7gCUq Z.sA4knnle_HCr3GViuyDJxDieNTWD7qQgzN.i.NFH5Dy.ygDA8eHvHvGv9V04EDSmOqwgL8BA7B 8eEQn1KoFixiIqtQySH.FAnukqfCbbP_wf28F X-Yahoo-Newman-Id: 125878.44295.bm@smtp136.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: B2Kax9MVM1md39W0oy_RJG6T5mvgLFqgunxH6tW51fDWeSu bzzu__CQ9BCwr4t3F2TsinLBIKGQHcbcwXpdIcQBk89WWZoVtbyHptFtCS0A YPlSD5hXnu4m_.dhqRbQLhwL0XW1qYSh8psebsQQJS.11bKYb27L2DPDs_nz PxAoi5VpVauNEyGzh1wbmEas7Y0i43gOBDKvKx893054MpDeG4vpiHuGtk6b 44SN2H6SR_QY.t_eBu.FiOPw0NACIDjDwPnDcVDcMXnyK60A17ogw9Y1a719 LL.fVVgKayHd7HlhyOiJPsTA1AFhFP8Iog5MYTRwScyJ5f_6zbqNzI0d05G7 0dqXZjofP5b5b_2E.8V3xh4dOZstL7vUKAfBc4IEm33egS8AZ98Ibs686dM_ H5ggyFWy7JV3DJr7wB1uOc8CJeWq0IX7gCUqZ.sA4knnle_HCr3GViuyDJxD ieNTWD7qQgzN.i.NFH5Dy.ygDA8eHvHvGv9V04EDSmOqwgL8BA7B8eEQn1Ko FixiIqtQySH.FAnukqfCbbP_wf28F X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- cc: zsh-workers@zsh.org In-reply-to: <1509554110.2494722.1158257296.27AEBF1E@webmail.messagingengine.com> From: Oliver Kiddle References: <7240.1507973844@thecus.kiddle.eu> <6529.1508164192@thecus.kiddle.eu> <20171016161151.6981579c@pwslap01u.europe.root.pri> <20171016164239.533e36fb@pwslap01u.europe.root.pri> <20171016174914.GO31613@andrew.cmu.edu> <21335.1508343802@thecus.kiddle.eu> <20171019143736.uzln5hj62tydskkr@tarpaulin.shahaf.local2> <5345.1509406703@thecus.kiddle.eu> <1509554110.2494722.1158257296.27AEBF1E@webmail.messagingengine.com> To: Daniel Shahaf Subject: Re: GH:zsh-users/zsh-completions. MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <14289.1509577133.1@thecus.kiddle.eu> Content-Transfer-Encoding: 8bit Date: Wed, 01 Nov 2017 23:58:53 +0100 Message-ID: <14290.1509577133@thecus.kiddle.eu> Daniel Shahaf wrote: > > 1) A suggestion was made to separate the completion functions out into a > > separate project but continuing to include the functions in zsh releases > > and the zsh git repository via git submodule. > Let's enumerate the advantages and see if there are other ways to > achieve them. (As you have done.) A further advantage relates to the following point that Julien raised: | | • If I send a compdef to zsh, what happens then ? We have to wait a least for | | the next release of zsh to delete it from zsh-completions. But then, not | | all distros update to the latest release of zsh, or the compdef could have | | evolved in zsh-completions in the meanwhile, so I can see this could be | | become quite a headache to manage (for users as well). Perhaps zsh-completions could add a separate directory containing functions that graduated to zsh. Copies of other functions that are newish in zsh might also go there, perhaps in backported form. Packagers would need to arrange for this to come at the end of $fpath which might be a little tricky. > I don't see a problem with encouraging patch submission via git??b or > any other channel, provided that (a) we are responsive over the channels > we advertise as 'official', (b) we don't split brain the discussions; i.e., > we continue to have just one forum for discussing patches that need > discussion (because they're controversial or invasive or ...). I assume that > forum would continue to be zsh-workers@. Yes, that's how I would envisage it. > I'd be happy to consider a different workflow for commits. The > requirement to first post your own patch and then copy the X-Seq header > before pushing it just adds work to maintainers for little benefit. (We > can continue to add X-Seq references when they're informative to the > commit or changelog message, of course.) > Note, I'd still love for there to be a mailing list that all commits' > diffs are emailed to --- diffs, not just notifications --- but that list > needn't be -workers@; it could be a separate list (say, zsh-commits@). If that removes the need to manually post patches for basic completion updates I'd be in favour of that. An option might be to have that only take commits that don't have an X-Seq reference in the commit message. > The remaining point is more frequent releases for completion. This > again brings compatibility questions, e.g., when we introduced the > typeset reserved word syntax, the completion in master wouldn't have > been usable by released zsh's; so we need some way to distinguish > Completions/ changes that are for master only from those that are > suitable for released versions too. I guess that boils down to maintaining > a git branch of the latest release that contains relevant Completions/ > commits? This would require maintainers to commit every patch twice, > though. I'd be happy enough to commit twice. We did that in the past with 3.0, 4.0 and 4.2 branches. But that approach also requires us to make releases of the branch. I alluded to something along these lines in 41908 ¶4. Backporting to the most recent release branch is rarely a big deal. Certainly compared to what a separate project might find users. expecting (RHEL 6 is in wide use still and has 4.3.11). Oliver