Hi all,
EuroPython is on the horizon and they have a new thing (or at least new for
me) called "helpdesk"
> Helpdesk / 10 slots
> Helpdesks are a great way to share your experience on a technology, by
offering to help people answering their questions and solving their
practical problems. You can run a helpdesk by yourself or with colleagues
and friends. Each helpdesk will be open for 3 hours in total, 1.5 hours in
the morning and 1.5 hours in the afternoon. People looking for help will
sign up for a 30 minute slot and talk to you. There is no specific
preparation needed; you just need to be proficient in the technology you
run the helpdesk for.
see: https://ep2017.europython.eu/en/call-for-proposals/
I would be interested to try this and volunteer to help with questions
about tox mainly. Would anybody else interested in that kind of thing? If
we find a handful of people that would want to do that, we could have a
tox/pytest/devpi helpdesk :)
Cheers,
Oliver
Hi Florian,
On Mon, 27 Mar 2017 at 22:47 Florian Schulze <fschulze(a)fastmail.fm> wrote:
> #450 isn't in the changelog of the link you sent.
oh right did not add that to the changelog yet. Will do that right away.
> Where is the magic for the issue linking? I'd like to add it to devpi.
linking code is here:
https://github.com/tox-dev/tox/commit/98b6a9c12cd00b8e7b8d71a6ad4bd7c91df42…
Cheers,
Oliver
Sory, sent this only to Florian yesterday I just noticed.
---------- Forwarded message ---------
From: Oliver Bestwalter <oliver(a)bestwalter.de>
Date: Sat, 25 Mar 2017 at 22:17
Subject: Re: [tox-dev] tox 2.7 is looming
To: Florian Schulze <mail(a)florian-schulze.net>
Hi,
On Sat, 25 Mar 2017 at 17:50 Florian Schulze <mail(a)florian-schulze.net>
wrote:
I hope to try it soon as well.
May I suggest that you add the changelog to the PyPI page? We have code for
adding the 5 latest ones in devpi:
https://bitbucket.org/hpk42/devpi/src/b21918c417867a2708e55f9bff5228a46cb3a…
Done. I pushed a 2.7.0 build now to my index, so that I can push that to
pypi next week right from there, if it is o.k.
https://devpi.net/obestwalter/dev/tox/2.7.0
Cheers,
Oliver
Hi all,
I just wanted to let you know that I pushed an unnecessary merge to master (
https://github.com/tox-dev/tox/commit/26354873eeb7062481342fa819aa583de2b0c…).
I still need to learn how to be a contributor who opens PRs to be reviewed
and a maintainer who does things directly on master at the same time. I
hope my push license won't be revoked because of this, but I take this as a
chance to ask for some feedback.
I don't know how the more experienced devs handle this, but this is my
current approach: if I see something that needs to be done that carries no
risk and is uncontroversial I just do it without bothering anyone. It's all
in the git history anyway. If I feel in any way insecure about the change,
I go the normal route (PR or Issue or writing on the mailing list).
Here are some things that fall into that first group for me:
* Fixing typos, fix broken links, improve grammar in docs
* Completing merged PRs like adding missing changelog entries or fixing
minor oversights
* changing long_description of the project, so the changelog entries of the
last 5 releases are shown on pypi (suggestion from Florian to do the same
as in devpi)
* fixed some problems due to a merged PR that turned out to be slightly
incomplete and lacked some test coverage (although there was something I
did not feel sure about which I reverted then).
* Preparing releases (bumping version numbers, etc.)
* etc. https://github.com/tox-dev/tox/commits?author=obestwalter
... so in short a lot of stuff that is not very exciting to do, but from my
current understanding part of the work of a maintainer. Those things are
utterly boring if somebody else is asked to look over it and it makes no
sense from my point of view to waste other peoples time with that.
This also includes things where it is more work and delay to remind
somebody else to do it instead of just fixing it yourself.
Here are some things I opened a PR or Issue for:
* Adding a Vagrantfile
* Changing the way versioning is handled (introducing setuptools_scm)
* Replacing all references to an old domain, where I was not quite sure if
it is really obsolete
* etc. https://github.com/tox-dev/tox/issues/created_by/obestwalter
So that's where I stand now and that is how I am planning to carry on,
unless I get new information that would lead me to reconsider that approach.
Cheers,
Oliver
Hi all,
the merged PRs start piling up, and we have a few new features but no
backwards incompatibilities I would know of, so I bumped the minor version
and pushed a dev version to my index:
https://devpi.net/obestwalter/dev/tox/2.7.0.dev1
The pace of development and the complexity of the fixes do not justify to
shower you with reams of text, so just have a look at the CHANGELOG and the
referenced issues for details.
I will be using that version over the next week for my projects at work and
release it next friday if everything stays quiet here.
The not yet merged PRs I would like to carry over into the next release as
some feedback would still be appreciated about the changing of the default
hook behaviours in https://github.com/tox-dev/tox/pull/450 and the
setuptools_scm switch is nothing really urgent, so that does not have to go
with 2.7 either.
Cheers,
Oliver
Hi all,
I started using projects for the tox issues:
https://github.com/tox-dev/tox/projects
Github projects are simple boards to provide additional views on the issues
and organize the flow of issues. It basically turns issues into virtual
post its, which then can be priritized and move along the different stages
of realization, it has very little overhead and I like that way of getting
organized.
the first "official" project is to prioritize the open bugs by severity to
be grabbed from the top for motivated bug squashers :) - see
https://github.com/tox-dev/tox/projects/1
I don't know if it is a good idea for a project like tox, but I will start
using this to get my own maintenance/OSS gardening work organized and maybe
it is interesting or helpful for other contributors as well.
Cheers
Oliver
Hi all,
I would like to establish a regular-ish release flow for tox and detox. PRs
are trickling in in a pleasant but not overwhelming number atm and I would
think that minor releases could be done quite often. I will try to make
releases as easy and foolproof as possible by adding a bit more automation
there.
Like I proposed somewhere else already, as a first step I will add Ronnies
setuptools_scm to handle versioning and a Vagrantfile that will make local
testing on Linux and Windows easier for contributors.
Related issues are: https://github.com/tox-dev/tox/issues/455 and
https://github.com/tox-dev/tox/issues/474
Cheers,
Oliver
