Re: Phobos.testing
On Sun, 11 Oct 2009 07:06:30 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei It's great for Boost, because Boost has an extremely large user base. Besides, Boost is large enough already and there are a lot of people who is willing to contribute, so a very strict policy is needed. Phobos is not like Boost. I believe a more open policy is required to make people contribute to it. For example, Tango is open to everyone, that's why it evolves so fast. Although small, contributions are made in a daily basis by a lot of people. They are not contributing entire libraries, of course, some small bug-fixes, performance improvements, typos, name change (for consistency), etc. Step-by-step it is getting better and better. On the contrary, Phobos has stalled. I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks.
Re: Phobos.testing
Denis Koroskin wrote: On Sun, 11 Oct 2009 07:06:30 +0400, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei It's great for Boost, because Boost has an extremely large user base. Besides, Boost is large enough already and there are a lot of people who is willing to contribute, so a very strict policy is needed. Phobos is not like Boost. I believe a more open policy is required to make people contribute to it. I need to say that having witnessed how Boost has evolved, what you say is simply not the case. Dave Abrahams has imposed from the very beginning very high standards. (I'm not saying that that's the only model that could work.) For example, Tango is open to everyone, that's why it evolves so fast. Although small, contributions are made in a daily basis by a lot of people. They are not contributing entire libraries, of course, some small bug-fixes, performance improvements, typos, name change (for consistency), etc. Step-by-step it is getting better and better. On the contrary, Phobos has stalled. I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei
Re: Phobos.testing
Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei For what it's worth, there seem to be about 206 open issues filed against phobos. http://d.puremagic.com/issues/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Phobosproduct=Dquery_format=advancedorder=version%2Cvotes%20DESC%2Cbug_idquery_based_on= More than I'd guessed before running the query. Later, Brad
Re: Phobos.testing
Andrei Alexandrescu wrote: ... I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei Are the preliminary submission and formal review open for anyone to participate in or watch? I would suggest taking advantage of traffic the newsgroups get to draw attention to them, be it only an announcement.
Re: Phobos.testing
On 2009-10-11 03:56:55 -0400, Denis Koroskin 2kor...@gmail.com said: I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Somehow I wonder if a distributed versioning system wouldn't be better to encourage public participation and make it easy for maintainers to accept patches. It'd be easy for me and others to maintain their own fork of Phobos with their own fixes while we test them, and for Phobos maintainers to review, select and merge back in the mainline any addition (whole branches or single commits) made in those forks. It'd be a much more automated process than applying patches from bugzilla, and that way you don't have to give access to the mainline to a lot of people. It'd require people to know the tool though. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Phobos.testing
Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. Phobos should probably use trac tickets. It would make it easier to range query phobos bugs.
Re: Phobos.testing
Lutger wrote: Andrei Alexandrescu wrote: ... I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei Are the preliminary submission and formal review open for anyone to participate in or watch? I would suggest taking advantage of traffic the newsgroups get to draw attention to them, be it only an announcement. At least in Boost, that's the case. Submissions go to the newsgroup and everybody can comment and/or vote. Andrei
Re: Phobos.testing
On 2009-10-11 14:13:22 +0200, Michel Fortin michel.for...@michelf.com said: On 2009-10-11 03:56:55 -0400, Denis Koroskin 2kor...@gmail.com said: I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Somehow I wonder if a distributed versioning system wouldn't be better to encourage public participation and make it easy for maintainers to accept patches. It would, systems like git make it far easier to fork/diff/merge than Subversion. Subversion is a bit of a pain, where you end up either having no version management except for a diff against the upstream repository or a local subversion tree that does not have a relation with the Phobos tree. Of course, you could partically go distributed by using git-svn to check out the Phobos Subversion repository. -- Daniel
Re: Phobos.testing
Brad Roberts wrote: Andrei Alexandrescu wrote: Sorry. I occasionally scan the bug reports and work on the Phobos-related ones, but I missed yours. I just assigned to myself four bugs you submitted. I think it should be fine to give you write and other regulars write access to Phobos. I'll ask Walter and Don. Andrei For what it's worth, there seem to be about 206 open issues filed against phobos. http://d.puremagic.com/issues/buglist.cgi?bug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDcomponent=Phobosproduct=Dquery_format=advancedorder=version%2Cvotes%20DESC%2Cbug_idquery_based_on= More than I'd guessed before running the query. Later, Brad Cool. One of these days I'll start using Bugzilla's search feature. I took over the bugs I think I can fix. Andrei
Re: Phobos.testing
Denis Koroskin wrote: I submitted a few Phobos bugs to bugzilla. They are still not addressed. Having 2-3 people with write access to Phobos is clearly not enough - there is not enough human power. That's bugzilla entries are left without answers, bugs are not fixed. I don't submit them anymore. It just doesn't work. I see a lot of quirks in Phobos, huge performance problems (it allocates every time, often without any reason) and just typos. Given a direct svn access, I could easily fix some of them, but I'm too lazy to waste my time on creating one line long patches, making bugzilla reports, etc. And what then? Waiting like 3 years until they are addressed? No, thanks. Denis, I have bad news for you: as a proof that you should be careful what you ask for, I got Walter's and Don's approval to add you to the Phobos developers roster. Please email me your dsource username. All, please join me in welcoming Denis to Cosa Nostra. People who want to gain write access to Phobos, please contact one of the admins (Brad, Walter, Don, Sean, or myself). The decision will be taken by vote on a per-case basis. Thanks, Andrei
Re: Phobos.testing
This discussion is great news. I will happily contribute to Phobos if the barriers are lowered enough. It would be worthwhile posting something on the announce newsgroup when you have some sort of improved contribution procedure worked out. Also, I would be happier with mercurial or git than with subversion.
Phobos.testing
I've noticed that it's somewhat difficult to get code into Phobos. This is somewhat understandable--noone wants a standard library full of buggy code that noone understands. On the other hand, it doesn't seem like there's a very well-organized process for getting stuff into Phobos if you're not a main contributor. Should something like a Phobos.testing lib be created? Such a project would be an area of dsource. The bar for getting stuff checked into here would be relatively low. If you write a module and check it into phobos.testing, it indicates that you believe that it would be generally useful enough to go into Phobos and are posting it for review/comment/other people to use with the caveat that it might not be well tested yet. This dsource project would use its own forums to comment on the code and debate about what does and doesn't belong in Phobos. Every release, Andrei would pick off the best well-tested, well-reviewed community-created feature and add it to the real phobos. Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here.
Re: Phobos.testing
On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. -- Michel Fortin michel.for...@michelf.com http://michelf.com/
Re: Phobos.testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 dsimcha wrote: I've noticed that it's somewhat difficult to get code into Phobos. This is somewhat understandable--noone wants a standard library full of buggy code that noone understands. On the other hand, it doesn't seem like there's a very well-organized process for getting stuff into Phobos if you're not a main contributor. Should something like a Phobos.testing lib be created? Such a project would be an area of dsource. The bar for getting stuff checked into here would be relatively low. If you write a module and check it into phobos.testing, it indicates that you believe that it would be generally useful enough to go into Phobos and are posting it for review/comment/other people to use with the caveat that it might not be well tested yet. This dsource project would use its own forums to comment on the code and debate about what does and doesn't belong in Phobos. Every release, Andrei would pick off the best well-tested, well-reviewed community-created feature and add it to the real phobos. Sounds like a good idea. At the mo, my biggest annoyance with D is the lack of a decent set of container classes in Phobos. Considering how D is supposed to be a superior c++, not having equivalents of the stl containers is a gob smackingly stupid omission. I'd be happy to port all of stl to D if it would be used and tested, though it would be better if it was redesigned with Andrei's ranges. Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. Yeah, bugzilla sucks ass. I hate not being able to browse it; you have to search and search only works if you happen to think in the same words as the person that files a bug. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFK0RlZT9LetA9XoXwRAstJAKCbJ/RjR/fApG3C+nB5Puc91JnHEwCg0jie jKvE3ScAAD3FPPKig33NK4A= =Shgw -END PGP SIGNATURE-
Re: Phobos.testing
Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei
Re: Phobos.testing
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei This sounds pretty good, except that I think it would be even better if the whole phobos.testing lib were easy for testers to download and install and play around with in non-production code. Actually using a library, even in toy/hobby projects, instead of just looking at it on paper makes it a lot easier to give informed opinions on it.
Re: Phobos.testing
dsimcha wrote: == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article Michel Fortin wrote: On 2009-10-10 19:01:35 -0400, dsimcha dsim...@yahoo.com said: Overall, the point is that there should be a well-defined process for getting code into Phobos and a well-defined place to post this code and comment on it. Bugzilla probably doesn't cut it because it's not easy to download, compile and test lots of different snippets of code from here. There should indeed be a process for proposing new modules or major features. I don't care much what it is, but it should make code available for review from all the interested parties, and allow public discussion about this code. Whether this discussion should happen on this newsgroup or elsewhere, I'm not sure however. And it'd be nice if it could auto-generate documentation from the proposed modules: glancing at the documentation often gives you a different perspective on the API, and it'd encourage people to write good documentation. I'm all for accepting additions to Phobos, and for putting in place a process to do so. I suggest we follow a procedure used to great effect by Boost. They have a formal process in place that consists of a preliminary submission, a refinement period, a submission, a review, and a vote. http://www.boost.org/development/submissions.html I compel you all to seriously consider it, and am willing to provide website space and access. Andrei This sounds pretty good, except that I think it would be even better if the whole phobos.testing lib were easy for testers to download and install and play around with in non-production code. Actually using a library, even in toy/hobby projects, instead of just looking at it on paper makes it a lot easier to give informed opinions on it. Yah, I think Boost has a sandbox that allows that. So, ready to submit your Rationals library? :o) Andrei
