digitalmars.D - D1 and Phobos Fixes
- Spacen Jasset (12/12) May 14 2009 Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed...
- Jason House (3/18) May 14 2009 Direct annonymous access can lead to quality control issues. I doubt tha...
- Andrei Alexandrescu (3/24) May 14 2009 HEY!!!
- Jason House (2/7) May 14 2009 I didn't say anything negative, I just don't know anything about your ea...
- Spacen Jasset (32/53) May 14 2009 Ok.
- BCS (5/21) May 14 2009 I don't known if dsource could be set up to do it but SVN allows per-pat...
- Walter Bright (7/9) May 14 2009 Many compiler patches get posted to bugzilla. About half of them are
- Spacen Jasset (2/13) May 15 2009 Yes fair enough. What about phobos? Do many patches for phobos come in?
- Don (4/17) May 15 2009 Not many Phobos patches have been posted. Phobos is quite different to
Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed out quicker by allowing certain members of the D community to commit changes to phobos directly. This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. I presume that all the bug fixes for phobos are incorporated by Walter, and wonder if this need by the case. Would it not be useful to have a "team" of some sort that can operate on phobos1 directly, and take submissions from the wider community. These fixes of course would be bug fixes only, and perhaps in some cases fixes where no behaviour has been defined, but existing behaviour is (clearly) wrong or non intentional.
May 14 2009
Spacen Jasset Wrote:Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed out quicker by allowing certain members of the D community to commit changes to phobos directly. This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. I presume that all the bug fixes for phobos are incorporated by Walter, and wonder if this need by the case. Would it not be useful to have a "team" of some sort that can operate on phobos1 directly, and take submissions from the wider community. These fixes of course would be bug fixes only, and perhaps in some cases fixes where no behaviour has been defined, but existing behaviour is (clearly) wrong or non intentional.Direct annonymous access can lead to quality control issues. I doubt that'll happen. It's much more reasonable to give write access on a case by case basis. If you want to make a case for yourself, start by adding quality patches into bugzilla. If they don't get no reaction, you can complain publicly on this newsgroup. More than just Walter has write access to Phobos. Andrei, Sean, and Don also have access. I'm pretty sure Don and Sean got access after frequent high quality contributions.
May 14 2009
Jason House wrote:Spacen Jasset Wrote:HEY!!! Andrei :o)Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed out quicker by allowing certain members of the D community to commit changes to phobos directly. This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. I presume that all the bug fixes for phobos are incorporated by Walter, and wonder if this need by the case. Would it not be useful to have a "team" of some sort that can operate on phobos1 directly, and take submissions from the wider community. These fixes of course would be bug fixes only, and perhaps in some cases fixes where no behaviour has been defined, but existing behaviour is (clearly) wrong or non intentional.Direct annonymous access can lead to quality control issues. I doubt that'll happen. It's much more reasonable to give write access on a case by case basis. If you want to make a case for yourself, start by adding quality patches into bugzilla. If they don't get no reaction, you can complain publicly on this newsgroup. More than just Walter has write access to Phobos. Andrei, Sean, and Don also have access. I'm pretty sure Don and Sean got access after frequent high quality contributions.
May 14 2009
Jason House <jason.james.house gmail.com> Andrei Alexandrescu Wrote:I didn't say anything negative, I just don't know anything about your early involvement with D. Your story is likely much different since I think you met Walter in a coffee shop.More than just Walter has write access to Phobos. Andrei, Sean, and Don also have access. I'm pretty sure Don and Sean got access after frequent high quality contributions.HEY!!! Andrei :o)
May 14 2009
Jason House wrote:Spacen Jasset Wrote:Ok. I did mean some "trusted" people rather than everyone, and I also mean perhaps someone(s) that can funnel patches in from the community, as a gatekeeper. I don't know if Andrei, Sean, or Don do that sort of thing on a regular basis. I don't mean to whine, but people here have, and continue complain about the rate of fixes from time to time. So perhaps for D1/phobos1 a case can be made for more of a community momentum as it were. It's just an idea. I have been following D's development for a few years now. Following is the word too, I haven't done much with it, so my contributions are minimal. I might aim to change that though. Can't sit around when there are projects to be worked on. Perhaps someone with commit rights could look at 2429 (has patch) or 2413 They aren't that important on the one hand, but on the other hand they are bugs. Perhaps since the focus will be switching to D2 it isn't so important for fix D1 bugs now anyway. Since this is the modern age of distributed revision control we could use such a system. I have played around with launchpad and bzr git and see that the model works quite well. (I am not necessarily suggesting bzr and launchpad here) While bugzilla patch files and svn work quite well. It is possible, and probably easier to stage branches in various states that people can pull from and then submit patches to, which ultimately can then potentially be put in the main phobos branch, and in the mean time people can pull down development branches to get the latest fixes that aren't in the official release yet. I am going off on all sorts of tangents here, but a colleague of mine has just ventured into D (After Andrei banded the D word about at the ACCU conference), and I think it could help a lot if people were able to contribute more easily to D/phobos or any other related projects. I am not sure I am getting across what I think I mean with all this waffle, so perhaps less of that and more doing is in order.Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed out quicker by allowing certain members of the D community to commit changes to phobos directly. This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. I presume that all the bug fixes for phobos are incorporated by Walter, and wonder if this need by the case. Would it not be useful to have a "team" of some sort that can operate on phobos1 directly, and take submissions from the wider community. These fixes of course would be bug fixes only, I dand perhaps in some cases fixes where no behaviour has been defined, but existing behaviour is (clearly) wrong or non intentional.Direct annonymous access can lead to quality control issues. I doubt that'll happen. It's much more reasonable to give write access on a case by case basis. If you want to make a case for yourself, start by adding quality patches into bugzilla. If they don't get no reaction, you can complain publicly on this newsgroup. More than just Walter has write access to Phobos. Andrei, Sean, and Don also have access. I'm pretty sure Don and Sean got access after frequent high quality contributions.
May 14 2009
Reply to Spacen,Since D1 is stable I wonder why bugs in Phobos1 and/or D can't be ironed out quicker by allowing certain members of the D community to commit changes to phobos directly. This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy. I presume that all the bug fixes for phobos are incorporated by Walter, and wonder if this need by the case. Would it not be useful to have a "team" of some sort that can operate on phobos1 directly, and take submissions from the wider community. These fixes of course would be bug fixes only, and perhaps in some cases fixes where no behaviour has been defined, but existing behaviour is (clearly) wrong or non intentional.I don't known if dsource could be set up to do it but SVN allows per-path access controls. It might be viable to ask for a more accessible branch (or branches) that people could play with and then have pieces merged back into the trunk.
May 14 2009
Spacen Jasset wrote:This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy.Many compiler patches get posted to bugzilla. About half of them are correct, the other half aren't (often fixing the symptom rather than the cause of the problem). Essentially, the compiler is fairly complicated and not well commented; I want to review any changes before they're committed. Otherwise I'll lose track of how it works and how it's supposed to work.
May 14 2009
Walter Bright wrote:Spacen Jasset wrote:Yes fair enough. What about phobos? Do many patches for phobos come in?This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy.Many compiler patches get posted to bugzilla. About half of them are correct, the other half aren't (often fixing the symptom rather than the cause of the problem). Essentially, the compiler is fairly complicated and not well commented; I want to review any changes before they're committed. Otherwise I'll lose track of how it works and how it's supposed to work.
May 15 2009
Spacen Jasset wrote:Walter Bright wrote:Not many Phobos patches have been posted. Phobos is quite different to the compiler, several of us have write access to it. It's well worth submitting patches for it.Spacen Jasset wrote:Yes fair enough. What about phobos? Do many patches for phobos come in?This goes for the compiler too, but presumably a lot of the the code is shared and it isn't so easy.Many compiler patches get posted to bugzilla. About half of them are correct, the other half aren't (often fixing the symptom rather than the cause of the problem). Essentially, the compiler is fairly complicated and not well commented; I want to review any changes before they're committed. Otherwise I'll lose track of how it works and how it's supposed to work.
May 15 2009