I also agree with that,and I would like to work on this with kunyu.
Jun-wei song (krnick)
___
core-workflow mailing list -- core-workflow@python.org
To unsubscribe send an email to core-workflow-le...@python.org
https://mail.python.org/mailman3/lists/cor
taff do the
boring-but-necessary bits so volunteers don't have to". (I think payment is
also appropriate for essentially "on call" roles like the security response
team)
Cheers,
Nick.
___
core-workflow mailing list
core-workflow@python.org
ing the same goal, but without the bias.
Good metrics are actually a useful way to know who to thank, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://
Anatoly, if you try to be part of this project, I will leave it. Your
complete lack of empathy for the point of view of others is not acceptable
in environments I am attempting to work in.
Regards,
Nick.
___
core-workflow mailing list
core-workflow
cludes some good
ideas for improvement.
For folks with greater Roundup-fu than me: how hard does the "personal
tags" idea sound? Alternatively, the front end could be more like a
personal set of "issue lists".
Cheers,
Nick.
>
> I'm not asking you to change or modify the proc
be kept after all?
>From a work queue perspective, two separate states likely makes sense,
since "Triage needed" & "Committer decision needed" are aimed at slightly
different groups of people (with the latter being a subset of the former).
That way, "Committer decision need
take it upon themselves to:
* write a comment on the issue tracker summarising the competing
perspectives and their pros and cons
* escalating the issue to python-dev for broader discussion (preferably
with a summary like the one above)
* for more radical/controversial notions, start a thread on pyth
s)
- tricky Python only issues (no keywords)
- trick C or C+Python issues (just the 'requires C' keyword)
I'm not particularly enamoured of that specific keyword name, so I'm
interested in two specific kinds of feedback:
1. Does the extra keyword sound useful?
2. Any othe
On 4 Aug 2014 09:37, "Ezio Melotti" wrote:
>
> Hi,
>
> On Sun, Aug 3, 2014 at 4:23 PM, Nick Coghlan wrote:
> > Chatting to an experienced C/C++ developer at PyCon AU today, they
> > were worried that their *Python* skills might not be good enough to
> >
complete lack of respect for my time
and energy, and a fundamental disagreement with the open source
principle of "those that do the work, make the rules".
Regards,
Nick.
___
core-workflow mailing list
core-workflow@python.org
https://mail.
unteer activity.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of
On 10 Feb 2015 01:34, "Brett Cannon" wrote:
>
>
>
> On Mon Feb 09 2015 at 6:15:22 AM Nick Coghlan wrote:
>>
>> As of earlier today, I've arranged to spend around 1 day of week of
>> paid time on CPython infrastructure work, focusing on container bas
POSIX systems
without affecting the host system (beyond installing Vagrant and
potentially VirtualBox), and Windows folks may even be able to figure out
how to automate that side of things as well (at least with an active MSDN
subscription).
Cheers,
Nick.
>
> -Brett
>
>>
>
h'ly yours,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct:
https:/
ay where CPython is concerned.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by th
ainerisation and related
development workflow improvements for open source services like
Kallithea was publicly announced last Friday:
http://connect.redhat.com/zones/containers :)
The relevant upstream bits are also there already
(https://github.com/projectatomic/adb-atomic-developer
h have been considered and discussed in the past.
>>
>> If it's aimed to committers/contributors (like the one Nick linked)
>> then we have to see if people wants something similar. Personally I
>> find importing a patch from the tracker (hg imp --no-c
>>
On 17 March 2015 at 01:36, Barry Warsaw wrote:
> On Mar 16, 2015, at 09:52 PM, Nick Coghlan wrote:
>
>>I've found one neat trick for this kind of scenario is to devise
>>standalone projects that are likely to be useful regardless of what
>>happens in the broader
ug you're currently looking at.
Another nice-to-have from my perspective would be the ability to add a
new comment without having to scroll back to the top of the
discussion.
Unfortunately, I suspect those would also qualify as being projects
best tackled under the R
On 22 March 2015 at 14:11, Ezio Melotti wrote:
> On Sat, Mar 21, 2015 at 9:33 PM, R. David Murray
> wrote:
>> On Sat, 21 Mar 2015 23:13:13 +1000, Nick Coghlan wrote:
>>> I don't think we've discussed it anywhere yet (unless I mentioned it
>>> to Ezio o
On 22 March 2015 at 23:16, Ezio Melotti wrote:
> On Sun, Mar 22, 2015 at 9:50 AM, Nick Coghlan wrote:
>> I did just remember another small item though - hooking up searching
>> by Real Name in addition to Username when adding someone to the nosy
>> list (not everyone uses
it of being easy to port to new VCS's later, since
"committer & commit message" is setting the "what metadata does the
VCS track?" quite low.
So your commit message might look like:
Apples are no longer counted as oranges
Apples were being counted as oranges
with links to the run logs
As we gained further familiarity and confidence with the system, we
could extend the trust for running pre-commit test runs to anyone that
has been granted Developer privileges on the issue tracker, rather
than restricting it specifically to core developers. (BTW, we shoul
racker improvements will likely get integrated around
> the end of GSoC.
\o/
Thank you for driving that.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
On 22 July 2015 at 04:03, Brett Cannon wrote:
> On Mon, Jul 20, 2015 at 7:15 PM Nick Coghlan wrote:
>> I think you're conflating some different issues here, at least two of
>> which are worth separating out from each other:
>>
>> 1. Completely online workflow for
the topic of a "Migrate CPython to
forge.python.org" follow-up PEP rather than the current PEP 474
proposal, and I'm not sure when I'm going to have a chance to write
that - PyCon Australia is next weekend, and then the weekend after I'm
off to the US for a couple of week
On 27 July 2015 at 08:45, Donald Stufft wrote:
> On July 26, 2015 at 6:22:44 AM, Nick Coghlan (ncogh...@gmail.com) wrote:
>> On 25 July 2015 at 14:47, Brett Cannon wrote:
>> > How would we handle
>> > changes that require custom fixes in two branches? They just
On 5 August 2015 at 08:26, Brett Cannon wrote:
> Nick and Donald, do you think you can have such a test setup up and running
> by October 31 (Halloween, 88 days away)?
I'm planning to use Kallithea as my guinea-pig project for user level
package management in Fedora, so this will be
On 5 August 2015 at 22:05, Nick Coghlan wrote:
> On 5 August 2015 at 08:26, Brett Cannon wrote:
>> Nick and Donald, do you think you can have such a test setup up and running
>> by October 31 (Halloween, 88 days away)?
>
> I'm planning to use Kallithea as my guinea-
s discussion is
that there *shouldn't be* a NEWS file in the repo itself - the repo
will contain the source data, but the rendering can happen separately
rather than being done incrementally on each commit. This means that
the renderer can be developed in parallel with the current process,
wi
e prefixes based on the commit hashes to be overridden.
>> >
>>
>> This is making me prefer MAL's #4 solution.
>
> I'm liking this solution as well...there's programming work to be done
> regardless, and adding a tracker field isn't *that* hard.
>
On 8 August 2015 at 08:25, Brett Cannon wrote:
> On Thu, Aug 6, 2015 at 7:17 PM Nick Coghlan wrote:
>> In the Roundup+Mercurial case, I think we can deal with this more
>> comprehensively by actually storing our canonical issue->commit
>> reference in *Roundup*, and menti
ements for merged
patches there as well, so they can be more readily queried
programmatically than they are today.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
lease let me know if there are specific next steps that would be most
> helpful.
And also whether there are areas where PSF grants may help in getting
these contributions integrated into the production services and
documentation.
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com |
with Mercurial and a Python based
hosting solution, I think the benefits of switching to a commercially
supported open source solution like GitLab outweigh those
considerations.
Regards,
Nick.
P.S. If anyone is really keen to continue advocating for the
Kallithea+Mercurial based solution, I'
On 5 Aug 2015 00:35, "Brett Cannon" wrote:
>
> Nick and Donald, do you think you can have such a test setup up and
running by October 31 (Halloween, 88 days away)? If you honestly need more
time I am willing to extend to November 15 (the cut-off in the retail
industry to consi
abling a more complex *opt-in* review
workflow in the future. While there's no counterpart to Reviewable for
GitLab that I'm aware of, the merge request API is rich enough to
enable one: http://doc.gitlab.com/ce/api/merge_requests.html (or, of
course, GitLab themselves may decide to implemen
, but we should get that clarified explicitly (since
we're still going to want to run pre-receive hooks like the
indentation checking one and the whitespace one, even if we also have
those checks automated in pre-merge CI).
Cheers,
Nick.
[1] http://doc.gitlab.com/ee/git_hooks/git_hooks.html
--
d away again.
This means that while I still favour retaining a welcoming environment
for strict free software advocates over going with a fully proprietary
SaaS option for our workflow, I also think the available export
options from GitHub are already good enough to ensure we're covered
from an i
k look through some of the command
line clients listed at https://about.gitlab.com/applications/, but
didn't see anything as workflow focused as git-pulls or hub, so "good
support for terminal based usage" may count as a concrete technical
differentiator here)
Cheers,
Nick.
--
Nic
review process:
http://doc.gitlab.com/ce/workflow/protected_branches.html
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
T
:
http://doc.gitlab.com/ee/workflow/ff_merge.html
That then further enables rebasing of merge requests via the browser:
http://doc.gitlab.com/ee/workflow/rebase_before_merge.html
> The GitLab-specific question is what, if anything, is GitLab prepared to
> offer us? Both Nick and Barry have
On 2 December 2015 at 09:24, Brett Cannon wrote:
> The GitLab-specific question is what, if anything, is GitLab prepared to
> offer us? Both Nick and Barry have hinted that GitLab would host us, listen
> to our needs, etc., but it has always seemed to be speculation. Do we have
&
ack to GitHub
2. A script akin to the PR->MR component of github2gitlab to create
and update MRs based on GitHub PRs
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@pyt
On 12 December 2015 at 10:24, Brett Cannon wrote:
> On Fri, 11 Dec 2015 at 07:33 Barry Warsaw wrote:
>> I know you want to make a decision soon, but IMHO we need to get these
>> issues
>> resolved before we can move forward.
>
> Yes, but we have all known Nick long
I've seen enough demands for
free software and privacy advocates to "stop being unreasonable" in
various contexts to suspect that an anonymous survey (that is still
somehow restricted to core developers) would be the only way to get an
even halfway accurate assessment.
Cheers,
Nick.
--
rite proprietary software, and being upset when folks use
the legal system to create an obligation for reciprocal sharing).
Regards,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@p
commits to master
should also eliminate most of the clutter from "git log", while still
presenting the meaningful changes to each branch.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflo
ad-write GitLab mirror in the
future, since the bot would handle the actual merge-and-commit process
based on review comments, regardless of which server was used to
submit the review.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
_
ce in use - if it was set up, any such mirror repo
would be read/write from a "you can submit and work with change
requests here", rather than "you can use git to push updates here".
Cheers,
Nick.
>
> Sent from my iPhone
>
>> On Dec 14, 2015, at 10:58 PM, Nick Co
a lot easier to appropriately
update a GitHub Pages based microsite than it is direct links to the
project repository on github.com.
It's also possible to use the CNAME support in GitHub Pages to move
the landing page out to a subdomain of another site.
Cheers,
Nick.
--
Nick Coghlan
dless of what else happens with the development workflow.
The idea also raises the question of how long we preserve
hg.python.org/cpython as a read-only Mercurial mirror of the new git
repo.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
will pass due
to prior testing in isolation, but has a separate feature that allows
PRs to be tagged for inclusion in "rollup" commits that land several
changes at once after testing them as a group)
The current merge queue for Rust itself can be seen at
http://buildbot.rust-lang.or
g position in various commercial contexts.
Since I'm also a strong advocate for tackling that problem at the
employer/employee boundary [1] rather than the vendor/customer one,
the case can even be made that GitHub's approach to changing that
dynamic (i.e. baking it in as an inhere
oject's release process:
https://github.com/hawkowl/towncrier
It's aimed more at projects with a simple linear release history
rather than CPython's branching sprawl, though.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
__
On 2 Jan 2016 07:37, "R. David Murray" wrote:
>
> On Fri, 01 Jan 2016 20:25:11 +, Stefan Krah <
skrah.temporar...@gmail.com> wrote:
> > Brett Cannon writes:
> > > I don't think this will be a shock to anyone who has followed the
> > discussion on this list. The decision is essentially based o
(Sorry, accidentally hit send while trying to discard a previous draft)
On 2 Jan 2016 11:17, "Nick Coghlan" wrote:
> On 2 Jan 2016 07:37, "R. David Murray" wrote:
> > Now, the fact that people felt it better to contact Brett privately to
> > advocate for Gi
r/Committer data
for old commits), which aren't generally relevant to future
contributors (so don't belong in the developer guide), but also
weren't part of the repository hosting decision making process (so
don't really belong in PEP 507).
Cheers,
Nick.
--
Nick Coghlan |
ne of the merges fails, then it's like branch
prediction in a CPU failing - you have to flush the pipeline and start
over again from the point of the failure.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-
;s repo shows what the PR interface looks like with Reviewable
enabled, for instance: https://github.com/pypa/pip/pull/3338 (there's
just an extra button to jump to the review in the external review
tool)
For the OpenStack workflow fans, there's http://gerrithub.io/
I can't find any exam
have a
lot of headroom before the main bottleneck becomes anything other than
availability of reviewers.
Cheers,
Nick.
P.S. While I think it would be overkill for CPython, folks working
with distributed systems may also be interested in a neat system
called ElasticRecheck that OpenStack use to identif
to/cherry pick into, and a NEWS entry (if necessary). I don't know if
> it needs to do anything else as a requirement. It should probably implement
> a commit queue like Zuul or Homu (and both of those can be considered as the
> basis of the bot). Also gating commits on passing a test r
he CPython
development process - each new maintenance release of CPython ships
the latest upstream version of pip, rather than being locked to the
version of pip that shipped with the corresponding x.y.0 release.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
pecifically looks up *those lines* in a coverage report, so it can
ensure that any lines changed by a patch are covered by the regression
test suite. It appears to be a neat way of guiding a code base towards
more comprehensive test coverage.
Cheers,
Nick.
--
Nick
On 5 January 2016 at 14:14, Nicholas Chammas wrote:
> Thanks for sharing that background, Nick.
>
> Instead, the main step which has been taken (driven in no small part
> by the Python 3 transition) is the creation of PyPI counterparts for
> modules that see substantial updates tha
he PR when it
> gets closed.
It also falls into the category of problem that a workflow bot
addresses - it just becomes a requirement for the bot to comment on
and close the original PR with a reference to the commit, in addition
to actually doing the commit itself.
Cheers,
Nick.
--
Nick Cog
S info at
least get a really clear indicator when we change version control
systems, even if they're not closely following upstream process
changes.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mail
ool
maintenance load with Mozilla rather than going for a completely
custom setup.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinf
. "core-workflow") under
https://github.com/python would likely be useful here, since it would
not only give people a place to collaborate on utility scripts, but
also an ad hoc issue tracker for tasks that don't have a more
appropriate home.
Cheers,
Nick.
--
Nick Coghlan | ncogh.
python moved over.
>
> As for a PSF account on dockerhub, I would ask the PSF infra team what they
> think and have them administer it.
A PSF account on DockerHub sounds like a good idea to me - that would
likely also be useful for hosting the reference image for the
manylinux1 build envir
exactly the same workflow. I think what Nick meant to show is,
> what we should target, more or less at least.
It was a combination of a suggestion and a question. The suggestion
was "Rust's automation UX seems nice, I think it would be desirable to
target similar capabilities for CPytho
o SourceForge in 2000,
all changes had to be funneled through the half dozen or so people
with write access to the CVS tree:
https://docs.python.org/3/whatsnew/2.0.html#new-development-process
I think it's definitely OK if future code archaeologists need to dig
into the SVN repository to get a more
date
* forget the previous step, and submit PRs against a stale version of master
I bring it up as when I first started using GitHub, the second way seemed
intuitively obvious to me, but it actually makes things harder than they
need to be.
Cheers,
Nick.
--
Nick
ertainly an available option, but
it's significantly more work for each patch than a persistent clone,
and also doesn't tolerate having multiple PRs in flight at once, so
I'm less worried about people choosing it naively without realising
the additional ha
On 7 March 2016 at 19:13, Nick Coghlan wrote:
> The audience here is folks that don't already have a preferred
> workflow for interesting with GitHub repos,
s/interesting/interacting/ :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane
On 6 Mar 2016 12:27, "Nick Coghlan" wrote:
>
> Something that came up at work recently was instructing people on how
best to configure local git clones for working with a "fork+PR" development
model, where you have your own server-side fork for the project that y
On 8 Mar 2016 03:23, "Barry Warsaw" wrote:
> On Mar 06, 2016, at 12:27 PM, Nick Coghlan wrote:.
>
> I think the essential bit of Nick's "easy way" is that you pretty much
ignore
> your fork's master. It's just too much work to try to keep it sync&
g, or some
combination thereof)
There's still value in a "check" CI run to see whether a patch is even
worth trying to commit, but it's a separate activity from actually
gating commits on the test suite passing.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail
relevant
to us even though we already have the developer guide :)
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-w
eliminate the "copy to hg.python.org" step.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
T
ike
Travis CI), why gate that on actually doing the migration first if we can
use the existing mirrors for it?
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://m
separation of the standard
library into "the cross-implementation bits" and "the CPython bits".
That said, I'd actually be in favour of doing such a structural split
*within* the repo (similar to the way we separated out the Programs
directory a while back), but e
ertain mundane review tasks (checking for CLA
signatures, running the tests) and switching to self-service
management of SSH keys for client authentication.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workf
On 31 August 2016 at 05:31, Anish Shah wrote:
> Hello everyone,
>
> as you all know, I was working on integrating GitHub into b.p.o under GSoC.
> This email is a summary of my work.
Very cool - thank you for your work!
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
a for us?
Probably not as part of the initial migration (since we don't have 2FA
now), but we should definitely be planning to enable it after the
migration is done and folks have settled into the new workflows.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Austral
me.
It may also be worth linking to
https://www.python.org/dev/peps/pep-0512/#commit-multi-release-changes-in-bugfix-branch-first
from this section of the devguide to help explain why we recommend
using the "work on master, cherry pick to maintenance branches"
approach.
Cheers,
Nick.
, and then push.
That note about "make sure it looks good" reminded me that "make
patchcheck" is going to need updating to handle git, which means
updating Tools/scripts/patchcheck.py
Brett, how would you like that extra task captured - PR to PEP 512?
Cheers,
Nick.
--
Nick
On 7 October 2016 at 13:26, Zachary Ware wrote:
> On Thu, Oct 6, 2016 at 10:10 PM, Nick Coghlan wrote:
>> That note about "make sure it looks good" reminded me that "make
>> patchcheck" is going to need updating to handle git, which means
>> updating Too
ommit --amend")
Recommending "--no-commit" as the default makes the first flow longer
by adding a separate commit step without actually simplifying the
others.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
and can be done from any client device".
While there will be cases where local client usage is needed (and
generating a backport PR will be one of them, unless/until GitHub
copies GitLab's cherry-pick-in-the-web-UI feature), allowing reviews
to be done that way is mainly for the benefit
compile-and-test aspect can be skipped, since it's just a docs change.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/co
d I think consistency there will be helpful, especially if the PSF
ends up approaching our CI provider regarding either a paid account or
an in-kind sponsorship.
So call it +1 for Travis CI, -0 for Circle CI (I don't think the
latter would be a *bad* choice, I just think Travis is a better c
nse to me. If you're so inclined, you may also want to take a
look at https://waffle.io/ as a possible way of visualising work in
progress.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
an extra org account in
another service.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is govern
ftware
into a pair of Linux container images and then host them wherever is
easiest for the PSF infrastructure team.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
___
core-workflow mailing list
core-workflow@python.org
htt
e number, rather than the downstream
one. Not especially necessary (we're well accustomed to the existing
naming scheme), but it doesn't hurt either.
So +1 to allowing "bpo 12345" from me, and +0 to continuing with only
issue12345 and issue 12345.
Could we get a pre-com
ndles autolinking of
references, since it assumes the JIRA instance is specific to a
particular organisation and lets you specify short prefix codes for
the projects.
One benefit of a hyphen based syntax would be reducing the temptation
to add in the "#" before the iss
hen compared to #
>
>
> I say try rewriting s/#(\d+)/bpo-\1/ and let's see how it turns out if
> you're up for it, Senthil (notice I went with the hyphen approach for
> "bpo-").
There's an added UX bonus to doing this: &quo
we'll have a
suitable format to take advantage of it
- even if "#(\d+)" does misfire on a few messages, it would be
relatively easy to mentally translate from "bpo-12345" back to
"#12345" in context
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com
ity, we'll have an easy time pointing both
pre-migration and post-migration commits to the right place.
Cheers,
Nick.
P.S. Note that all the old SF issues were imported into b.p.o with
their original issue numbers, so it's entirely correct to translate
"SF #433233" in
1 - 100 of 145 matches
Mail list logo
