Coordinating further development #908
Comments
What do you mean? Is your target for more people to get commit rights? |
|
I guess @toogley point was to give someone commit rights, because otherwise project is starting to stagnant (47 open PRs). |
|
I would be happy to hand over commit rights to interested an capable developers!
My only concern is to ensure some kind of quality control to avoid that
people blindly push large, unmaintainable changes.
I would for instance be very happy to have some kind of referee system
like in notmuch, where patches are only pushed to master once approved.
But this would require a nontrivially large developer base..
I'm open for proposals :)
Quoting Anton Parkhomenko (2016-12-01 09:19:16)
… I guess ***@***.*** point was to give someone commit rights, because
otherwise project is starting to stagnant (47 open PRs).
—
You are receiving this because you were mentioned.
Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.
Reverse link: [4]unknown
References
Visible links
1. https://github.com/toogley
2. #908 (comment)
3. https://github.com/notifications/unsubscribe-auth/AAmW54ykULSRii03SvPbGInh-PiIC76Qks5rDpEUgaJpZM4LAdvu
4. #908 (comment)
|
|
Hi, all! It would be great to see a more active alot! There seems to be some people willing to collaborate with development, but coordinating it, despite @pazz efforts, is no easy task. =P I share his worries about quality control and also fear the creation of a frankenstein if we just add features without a common vision for the project. Not sure how many people there are willing to help with that, but maybe creating an email list we could better discuss priorities for the project, concentrate efforts and call attention to some open issues. On my part, being sincere, I wouldn't assume the commitment to review PRs, but maybe I could help in some cases. I'm willing to help with the merge of #896 (or an equivalent alternative) and with a better visualization for HTML messages (colors, bold, italic, links). |
|
Great :) @TomasTomecek Improvements I wish are:
|
|
@pazz additionally, i think github allows to prohibit direct commits to master. that way, we can make sure that every pull request has been controlled for quality. |
|
@toogley Github also has a review process similar to what traditional open source projects do via mailing lists or more centralized systems like gerrit (although maybe not as warty as Gerrit). Gerrit is pretty painful to work with since it doesn't handle series well. |
|
@dcbaker do you (or anyone else) have experience with QA tools in github? |
|
On Fri 2016-12-02 04:10:26 -0500, Patrick Totzke wrote:
I would also not mind using a workflow like notmuch does, via a mailinglist.
I suspect we could ask the notmuchmail.org site admins to set up
alot@notmuchmail.org if we wanted to. I wouldn't even be surprised if
no one objected to posting alot patches to the main notmuch mailing list
as long as they were marked explicitly with [ALOT PATCH], like so:
git config format.subjectPrefix 'ALOT PATCH'
git config sendemail.to notmuch@notmuchmail.org
…--dkg
|
|
Quoting dkg (2016-12-02 13:58:22)
On Fri 2016-12-02 04:10:26 -0500, Patrick Totzke wrote:
> I would also not mind using a workflow like notmuch does, via a
mailinglist.
I suspect we could ask the notmuchmail.org site admins to set up
***@***.*** if we wanted to.
Maybe this would be nice to have regardless of how we proceed.
I wouldn't even be surprised if
no one objected to posting alot patches to the main notmuch mailing list
as long as they were marked explicitly with [ALOT PATCH], like so:
git config format.subjectPrefix 'ALOT PATCH'
git config sendemail.to ***@***.***
yes, possible. I was actually not going to abandon the github PR system
alltogether in favour of mailinglist-circulated patches, because i quite
like the github interface. I thougt more along the lines of ML-threads
for each github PR or so.. but come to think of it, we can just as well
use githubs issue comments for this discussion and some of the above
mentioned github addons to formalize reviews/approvals.
|
|
@pazz I've used the integration for AppVeyor and Travis (which are CI systems for windows and Linux/OSX respectively, for those who aren't aware) and I've played just a bit with coveralls. It's not that hard to set up, and that integration is the killer feature over using a mailing list IMHO. Really getting it all setup isn't that hard, you write a .travis.yml file that lives in the repo, and then set the repo to refuse merges that don't pass your checks. I've used pylint, pyflakes, and toyed a bit with mypy with Travis. My experience is this: traditional open source developers know and love mailing lists, they have their tools setup and like it. I have my tools (alot and vim) set up for efficient mailing list work, but it's taken me a while to get that set up, so it's a barrier to entry, especially for drive by developers. Maybe alot's nature lends itself well to that since most of its main audience is developers, I'm not sure. I think github's tight integration with milestones, releases, bug tracking, and CI; coupled with its wide audience is an advantage. Other projects have also found it's helpful for getting drive-by contributions because of that wide audience and hte ease of sending pull requests, systemd comes to mind as a high profile project to switch from a mailinglist to github. Just my two cents. |
|
Thanks for this Dylan.
I am of course willing to give all this a try. Automated pyflakes-based
checks for instance sound like a great thing to have if it integrates into github.
I would also favour github over mailinglists even if it's just to keep
those "drive-by" contributions comming in since, in my experience, some
of them were well worth having.
Maybe it'd be a good time to make a release and flush out some of the
more stable PR's, and then set up a new infrastructure for the next cycle.
Who would be interested in the day-to-day upkeep of this project? That
is, who wants / should get write access in your opinions?
I would check those candidates' past contributions and grant these
rights accdordingly (once I've figured out how).
So hands up, don't be shy :)
Quoting Dylan Baker (2016-12-02 18:32:44)
… ***@***.*** I've used the integration for AppVeyor and Travis (which are CI
systems for windows and Linux/OSX respectively, for those who aren't
aware) and I've played just a bit with coveralls. It's not that hard to
set up, and that integration is the killer feature over using a mailing
list IMHO. Really getting it all setup isn't that hard, you write a
.travis.yml file that lives in the repo, and then set the repo to refuse
merges that don't pass your checks. I've used pylint, pyflakes, and toyed
a bit with mypy with Travis.
My experience is this: traditional open source developers know and love
mailing lists, they have their tools setup and like it. I have my tools
(alot and vim) set up for efficient mailing list work, but it's taken me a
while to get that set up, so it's a barrier to entry, especially for drive
by developers. Maybe alot's nature lends itself well to that since most of
its main audience is developers, I'm not sure. I think github's tight
integration with milestones, releases, bug tracking, and CI; coupled with
its wide audience is an advantage. Other projects have also found it's
helpful for getting drive-by contributions because of that wide audience
and hte ease of sending pull requests, systemd comes to mind as a high
profile project to switch from a mailinglist to github.
Just my two cents.
—
You are receiving this because you were mentioned.
Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.
Reverse link: [4]unknown
References
Visible links
1. https://github.com/pazz
2. #908 (comment)
3. https://github.com/notifications/unsubscribe-auth/AAmW5wa25eOX4nCNNkGnjvVEFq5ikebqks5rEGRMgaJpZM4LAdvu
4. #908 (comment)
|
|
On Fri 2016-12-02 16:03:47 -0500, Patrick Totzke wrote:
Who would be interested in the day-to-day upkeep of this project? That
is, who wants / should get write access in your opinions?
I would check those candidates' past contributions and grant these
rights accdordingly (once I've figured out how).
So hands up, don't be shy :)
I can't afford the time to do day-to-date upkeep of the project, but i'm
willing to review and contribute code and bugfixes for the
OpenPGP-related parts of the project.
…--dkg
|
I also can't afford the time for this role - nor do i have the experience for that. However, i certainly can help the project with small contributions (for instance, i'm interested in implementing the unit tests, but i don't know when i will have time to do that). But, is there a reason why we don't maintain the project altogether, instead of few dedicated people? (by that i mean the "day-to-day upkeep of this project") |
|
I like at @toogley's suggestion, I too can help with maintenance because I rely on alot for my day job, I can't be the maintainer. I've been involved in several projects that don't have a single maintainer and as long as everyone is willing to commit to the rules (reviews, CI, etc) then it can work very well. |
|
Right. I wasn't asking anyone to completely take care of the "day-to-day upkeep"
alone, but to commit to making regular contributions, be in in the form
of reviews of take part in discussions when to make releases or the
like. I interpret your messages as indicating interest in this, and I'm
more than happy to give you edit rights here.
Quoting Dylan Baker (2016-12-03 23:07:56)
… I like at ***@***.***'s suggestion, I too can help with maintenance
because I rely on alot for my day job, I can't be the maintainer. I've
been involved in several projects that don't have a single maintainer and
as long as everyone is willing to commit to the rules (reviews, CI, etc)
then it can work very well.
—
You are receiving this because you were mentioned.
Reply to this email directly, [2]view it on GitHub, or [3]mute the thread.
Reverse link: [4]unknown
References
Visible links
1. https://github.com/toogley
2. #908 (comment)
3. https://github.com/notifications/unsubscribe-auth/AAmW5w-Aj0O_YS_TKymGMk3VI8Xz2vnSks5rEfZMgaJpZM4LAdvu
4. #908 (comment)
|
|
I will continue to follow the development of alot :) but I will wait some time longer until I ask for commit rights. (I am behind on my own PRs even.) I tried to add a travis file some time ago. Maybe it is interesting for setting up a new work flow before or after the next release: #886 I vote for github over mailinglists as it integrates git+issues+ci(plugins). @toogley I am sceptical about automatically applying PEP 8 changes. Whenever I used PEP 8 helper tools I had to check stuff manually. I like travis and tests though (see #886 for example). |
|
I mean readability. Especially hanging indent or continued indent was a manual decision to achieve best readability and minimum line length. Syntax was never a problem. My main concern was actually about having the files modified (and changes committed) automatically. But if I read the introduction for yapf some more times I might be won over by the idea to have it automated. |
|
Perhaps this will motivate me to find some time to fix the python 3 PR and I also have some bits and pieces around for fixing #830. Also, I'm an owner of the PyPI package, will gladly transfer/share ownership with anyone from the team. |
|
@lucc: yapf looks nice indeed. any way this can be build into the github workflow? |
|
@dcbaker commented 6 days ago
👍 I think this new'ish workflow is really quite nice. @toogley commented 7 days ago
If you protect a branch like that, not only can you make at least one positive review mandatory, you could eventually enforce that your tests pass on some CI provider. Sounds like a solid start to me. @toogley commented 2 days ago
Isn't that a client side hook? I imagine it would be hard to make sure contributors actually setup such a hook (other than demanding it in a guideline). |
|
i totally overlooked this new review feature, nice! |
|
@pazz if that release happens before January 27, then we can have it in the next Debian stable release. :) |
|
good to know, thanks josh!
|
|
On Thu 2016-12-08 10:46:45 -0500, josch wrote:
@pazz if that release happens before January 27, then we can have it
in the next Debian stable release. :)
it needs to be significantly before January 27. Please do not wait
anything close to that long. Relevant dates for debian are here:
https://lists.debian.org/debian-devel-announce/2016/11/msg00002.html
Note the 10-day lead time for many of these things, and that only gets
worse if you have bugs that need ironing out.
…--dkg
|
|
@pazz can i have contribution rights? I have some time this weekend, so i could categorize the issues and pull requests in labels, etc.
Yeah, it is and your argument is very reasonable. One alternative would be that a script pulls the current state of master, reformats it according to PEP8 and commits it to master with a commit string like |
|
Quoting Tobias Angele (2016-12-08 20:05:14)
***@***.*** can i have contribution rights? I have some time this weekend, so
i could categorize the issues and pull requests in labels, etc.
Thanks for the offer, but I'd rather you would help rebase some PR's to
the new master branch or things like that first.
I'm holding back with giving you write access for now, since you haven't
made any commits until now. I hope you understand :)
***@***.***
i think we could use the pre-commit git hook for that.
Isn't that a client side hook? I imagine it would be hard to make sure
contributors actually setup such a hook (other than demanding it in a
guideline).
Yeah, it is and your argument is very reasonable. One alternative would be
that a script pulls the current state of master, reformats it according to
PEP8 and commits it to master with a commit string like automatic code
formatting or sth like that. But i'm not sure how beautiful/readable that
solution is, as its kind of "polluting" the commit tree.
I have acticated some QA bot for this repository that, at least in
theory, should automatically check out, validate and comment on new pull
requests from now on.
My plan is to push #883 (once rebased), make a release and from then on
require further PR's to satisfy this pep8-codenazi bot.. thoughts?
|
|
@toogley I've found it preferable to attach pylint or pyflakes to the CI system and refuse commits that fail CI. One of the advantages is that a human looks at the style issue and either fixes it or uses a pylint or pyqa comment to ignore style issues that don't make sense, for example a line that is 81 characters long but doesn't make sense to wrap. I think it's also worth starting to lay out some of the goals for the project going forward so we can start discussing how we want to go about them. Personally, I think getting good unit testing is going to be immensely helpful, especially if porting to python 3.x is another goal that we want. And talking about whether we want to port to python 3.x or support a hybrid codebase. |
|
On Thu 2016-12-08 22:21:24 -0500, Dylan Baker wrote:
I think getting good unit testing is going to be immensely helpful,
especially if porting to python 3.x is another goal that we want. And
talking about whether we want to port to python 3.x or support a
hybrid codebase.
I think both unit tests and python 3 compatibility are great concrete
goals that could encourage more (and easier) contributions from others
in the future too.
I don't much care whether alot ends up with a hybrid codebase or is
simply python3-only. python3 should be pretty much universally
available on any system that is sane to run an MUA on these days.
…--dkg
|
|
Quoting dkg (2016-12-09 04:26:20)
I think both unit tests and python 3 compatibility are great concrete
goals that could encourage more (and easier) contributions from others
in the future too.
I don't much care whether alot ends up with a hybrid codebase or is
simply python3-only.
My view exactly.
|
|
Fore those of you that are interested in buildind/linting/testing the code on travis.ci I invite you to have a look at #886 again. It sets up a minimal travis file. Later we can add jobs for linting and unittesting if we want. |
|
The old milestone for 0.4 is now kind of obsolete. should we copy or rename it to 0.5? @pazz would you like me/us to add labels to issues? |
|
Quoting Lucas Hoffmann (2016-12-10 07:41:20)
The old milestone for 0.4 is now kind of obsolete. should we copy or
rename it to 0.5?
***@***.*** would you like me/us to add labels to issues?
Sure, why not.
And yes: The milestone is obsolete and should be updated. Maybe we
should agree on a new one for 0.5.
I like the idea of prioritizing unit tests for now.
Btw: I will hang out on #alot @ freenode. We don't need to hijack
#notmuch for these discussions..
|
|
I think this issue has run its course. Any objections to closing this? |
|
agreed. |
|
@pazz Btw. Sorry, i completely underestimated your activity. |
|
no worries :) Its just that life goes on you know, and alot is not always on the top of my list.. |
Hey.
It seems this project is quite interesting as well for users and developers. (according to the github stars and the amount of pull requests)
But unfortunately, @pazz seems to loose interest in this project, as his development in this project is rather low. Therefore, I want to ask about establishing a kind of community around this project - are you guys interested? I am certainly.
@pazz What do you think about this idea?
/cc
@xunam @MacGyverNL @andresmrm @dcbaker @lucc @meskio @np @meskio @adqm @genkimarshall @adqm
@dkg
@quite
@hildensia
@stapelberg
@acoolon
@a3nm
@t-8ch
@josch
@yannrouillard
@posativ
@laarmen
@kazuoteramoto
@pipejakob
@GuillaumeSeren
@foobacca
@mpnordland
@cinghiopinghio
@meskio
@geier
@TomasTomecek
@lzap
@andresmrm
@windo
@nookieman
@tomprince
@jrollins
@tcheneau
@elenril
@chuwy
@goneri
@xunam
@jakeogh
@mturquette
@JohannWeging
The text was updated successfully, but these errors were encountered: