lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ernst <r...@iernst.net>
Subject Re: git email format customizability: add branch to subject?
Date Sat, 20 Feb 2016 01:04:40 GMT
This sounds good, but isn't the repo name redundant given it is implied by
the email going to commits@l.a.o?
On Feb 19, 2016 4:38 PM, "Chris Hostetter" <hossman_lucene@fucit.org> wrote:

>
> : https://git-wip-us.apache.org/docs/switching-to-git.html seems to
> : suggest there is per project flexibility. Branch not one of the
> : (currently) available variables though, no?
> :
> : +1 for "the branch be included in the subject"
>
> Thanks for finding that link Christine,
>
> I pinged #infra on HipChat to try and find the actual code in question to
> see how hard it would be to add "branch" based variables so I could
> propose a patch to infra rather then just a general "can we do this?" type
> request, but aparently that code is ASF specific and lives in a private
> infra repo, so only infra members can read/write.  Gavin said new subject
> variables are usually not a big deal though.
>
> That said, before I request any changes, I want to make sure I'm
> not wasting the time of any infra volunteers -- so I'd like to make sure
> we have some concensus on what we'd ideally like...
>
>
> : Perhaps the script could only include the last N elements of the name,
> : so we get lucene-5438-nrt-replication or
> : jira/lucene-5438-nrt-replication instead of the full branch name.  Or
> : maybe a regex could be used to target refs\/.*?\/ (or something more
> : complex) for removal -- for some of the existing branch names, having
> : the last three path elements would be good, but for others, one or two
> : would be better.
>
> good point ... given that this is a general infra tool for all projects,
> and currently the only per-project configuration is (aparently) what the
> subject should be comprised of, i'm hesitent to try and request a lot of
> custom regex rules, and/or making any general assumptions about only using
> the last "N" elements of the name.
>
> (a common workflow i've seen is things
> like refs/head/jira/solr-xyz for a shared collaboration on that feature,
> while refs/head/hossman/jira/solr-xyz might be my proposed new direction
> for the code to take -- we wouldn't want those to get confused.)
>
> That said, i think it would totally make sense to request that
> "%(branch)s" should refering to the full branch path, and
> "%(shortbranch)s" should be the result of regex stripping
> "^refs\/(heads\/)?" from the full branch path.
>
> So "refs/heads/branch_7_5 => "branch_7_5"
>
> But "refs/tags/releases/lucene-solr/7.5.0"
>  => "tags/releases/lucene-solr/7.5.0"
>
> : There is normally a fairly limited amount of space for the subject in
> : the list view of an email client, so it seems like a good idea to keep
> : it short but relevant.
>
> Agreed -- so perhaps we should also request reducing some other
> redundencies? (ie: "git commit")
>
>
> what do folks think about requesting as our pattern...
>
>   "git: %(repo_name)s:%(shortbranch)s: %(subject)s"
>
>
> With some examples of what that would look like for a handful of commits
> from the past month...
>
>
> git: lucene-solr:branch_5x: fix test bug, using different randomness when
> creating the two IWCs
>
> http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3Ca9231a5cb3444a9ba70f1b67658d2844%40git.apache.org%3E
>
> [1/3] git: lucene-solr:lucene-6835: cut back to
> Directory.deleteFile(String); disable 'could not removed segments_N so I
> don't remove any other files it may reference' heroics
>
> http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3C68acb868408348da8941e473725abda0%40git.apache.org%3E
>
> [1/2] git: lucene-solr:master: LUCENE-7002: Fixed MultiCollector to not
> throw a NPE if setScorer is called after one of the sub collectors is done
> collecting.
>
> http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3Ca53313b79d1b4286a655b03d2e2b217f@git.apache.org%3E
>
> [2/2] git: lucene-solr:branch_5x: LUCENE-7002: Fixed MultiCollector to not
> throw a NPE if setScorer is called after one of the sub collectors is done
> collecting.
>
> http://mail-archives.apache.org/mod_mbox/lucene-commits/201602.mbox/%3C40d0b62a4e2245ff85211c4fe4401f43@git.apache.org%3E
>
>
> ...note in particular those last two emails.  As I understand it they
> were two commits from the same "push", on diff branches (the master change
> and the 5x backport) ... which is now more clear with the branch name in
> the subject.
>
> Are folks in favor of requesting this from infra?
>
>
>
> -Hoss
> http://www.lucidworks.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Mime
View raw message