Thread: [myhdl-list] Github staging and works in progress
Brought to you by:
jandecaluwe
From: Henry G. <he...@ca...> - 2015-07-14 18:10:28
|
As was raised during PR #102 on github, Jan's preference so far has been to have PRs that are complete and ready. I posit that allowing discussion and updates on specific implementation is a great feature of github and we should have a convention to allow for this, such that a solution can evolve with input inside a PR. @jck's suggestion of doing what neovim do seems like a great idea to me: Prefixing the title with one of the following tags: |[WIP] - Work In Progress: the PR will change, so while there is no immediate need for review, the submitter still might appreciate it. [RFC] - Request For Comment: the PR needs reviewing and/or comments. [RDY] - Ready: the PR has been reviewed by at least one other person and has no outstanding issues. | Only when the tag is changed to [RDY] is it deemed to be ready for inclusion. It would be great if github had a collaborative staging area, but this seems like a good solution to me. On a similar vein, I've sometimes failed to get useful feedback on specific implementations that are distinctly a work in progress, but need feedback to proceed. Specifically, issue #68 in which I have half of a complete implementation for that particular problem. It's distinctly not PR ready, but is a WIP. I'm somewhat disinclined to sink any more time into it without some further constructive feedback, which I attempted to garner without much success. I feel there is quite a bit that could be done very easily to make contributors feel more welcome. A mechanism for better and more patient code collaboration for WIPs would go a long way to this end. Perhaps if Jan doesn't wish to be involved with this, a second mirror repository on github could take on that role. Cheers, Henry |
From: Christopher F. <chr...@gm...> - 2015-07-15 12:59:53
|
On 7/14/2015 1:10 PM, Henry Gomersall wrote: > As was raised during PR #102 on github, Jan's preference so far has > been to have PRs that are complete and ready. > > I posit that allowing discussion and updates on specific > implementation is a great feature of github and we should have a > convention to allow for this, such that a solution can evolve with > input inside a PR. > > @jck's suggestion of doing what neovim do seems like a great idea to > me: > > Prefixing the title with one of the following tags: > > |[WIP] - Work In Progress: the PR will change, so while there is no > immediate need for review, the submitter still might appreciate it. > [RFC] - Request For Comment: the PR needs reviewing and/or comments. > [RDY] - Ready: the PR has been reviewed by at least one other person > and has no outstanding issues. | > > Only when the tag is changed to [RDY] is it deemed to be ready for > inclusion. If we agree on this (it sounds reasonable) we need to update the development guide - stamp it official :) http://dev.myhdl.org/guide.html#creating-changes > > It would be great if github had a collaborative staging area, but > this seems like a good solution to me. > > On a similar vein, I've sometimes failed to get useful feedback on > specific implementations that are distinctly a work in progress, but > need feedback to proceed. Specifically, issue #68 in which I have > half of a complete implementation for that particular problem. It's > distinctly not PR ready, but is a WIP. I'm somewhat disinclined to > sink any more time into it without some further constructive > feedback, which I attempted to garner without much success. In my opinion this is an effect of limited resources and distributed development. An OP needs to be patient and persistent with issues. For example, we had some off in the weeds conversations on IRC, so naturally this task faded into the background. > > I feel there is quite a bit that could be done very easily to make > contributors feel more welcome. A mechanism for better and more > patient code collaboration for WIPs would go a long way to this end. > Perhaps if Jan doesn't wish to be involved with this, a second mirror > repository on github could take on that role. A second mirror is not needed, when we first started discussing this issue fetching from each others forks worked fine and isn't too difficult. I think the process outlined in the developer guide is reasonable first communicated (issues, IRC, gitter, mailing-list), and git provides reasonable collaboration. Adding the tags could also be useful (I think it will also have some unforeseen downsides, e.g. staleness, who decides when a WIP is dead). http://dev.myhdl.org/guide.html#first-step-communicate Regards, Chris |
From: Henry G. <he...@ca...> - 2015-07-15 13:11:45
|
On 15/07/15 13:59, Christopher Felton wrote: > On 7/14/2015 1:10 PM, Henry Gomersall wrote: >> >As was raised during PR #102 on github, Jan's preference so far has >> >been to have PRs that are complete and ready. >> > >> >I posit that allowing discussion and updates on specific >> >implementation is a great feature of github and we should have a >> >convention to allow for this, such that a solution can evolve with >> >input inside a PR. >> > >> >@jck's suggestion of doing what neovim do seems like a great idea to >> >me: >> > >> >Prefixing the title with one of the following tags: >> > >> >|[WIP] - Work In Progress: the PR will change, so while there is no >> >immediate need for review, the submitter still might appreciate it. >> >[RFC] - Request For Comment: the PR needs reviewing and/or comments. >> >[RDY] - Ready: the PR has been reviewed by at least one other person >> >and has no outstanding issues. | >> > >> >Only when the tag is changed to [RDY] is it deemed to be ready for >> >inclusion. > If we agree on this (it sounds reasonable) we need > to update the development guide - stamp it official:) > > http://dev.myhdl.org/guide.html#creating-changes Well, this gets my vote. > >> > >> >It would be great if github had a collaborative staging area, but >> >this seems like a good solution to me. >> > >> >On a similar vein, I've sometimes failed to get useful feedback on >> >specific implementations that are distinctly a work in progress, but >> > need feedback to proceed. Specifically, issue #68 in which I have >> >half of a complete implementation for that particular problem. It's >> >distinctly not PR ready, but is a WIP. I'm somewhat disinclined to >> >sink any more time into it without some further constructive >> >feedback, which I attempted to garner without much success. > In my opinion this is an effect of limited resources and > distributed development. An OP needs to be patient and > persistent with issues. For example, we had some off in > the weeds conversations on IRC, so naturally this task > faded into the background. No doubt. The problem was more that there was nowhere that seemed to right to have the necessary conversation. My mild apathy to the problem meant that I'm not being particularly persistent (it was an issue that I thought was interesting and could see the purpose, but wasn't relevant to me - my approach was largely an academic exercise to see if it could be done without too much difficulty). >> > >> >I feel there is quite a bit that could be done very easily to make >> >contributors feel more welcome. A mechanism for better and more >> >patient code collaboration for WIPs would go a long way to this end. >> >Perhaps if Jan doesn't wish to be involved with this, a second mirror >> >repository on github could take on that role. > A second mirror is not needed, when we first started > discussing this issue fetching from each others forks > worked fine and isn't too difficult. I think the > process outlined in the developer guide is reasonable > first communicated (issues, IRC, gitter, mailing-list), > and git provides reasonable collaboration. Adding the > tags could also be useful (I think it will also have > some unforeseen downsides, e.g. staleness, who decides > when a WIP is dead). I agree that would be a bad outcome. It was really whether title tags are acceptable for the proposed kinds of PR in the main repository. Cheers, Henry |
From: Jan D. <ja...@ja...> - 2015-07-16 08:29:17
|
On 07/14/2015 08:10 PM, Henry Gomersall wrote: > As was raised during PR #102 on github, Jan's preference so far has > been to have PRs that are complete and ready. > > I posit that allowing discussion and updates on specific > implementation is a great feature of github and we should have a > convention to allow for this, such that a solution can evolve with > input inside a PR. > > @jck's suggestion of doing what neovim do seems like a great idea to > me: > > Prefixing the title with one of the following tags: > > |[WIP] - Work In Progress: the PR will change, so while there is no > immediate need for review, the submitter still might appreciate it. > [RFC] - Request For Comment: the PR needs reviewing and/or comments. > [RDY] - Ready: the PR has been reviewed by at least one other person > and has no outstanding issues. | > > Only when the tag is changed to [RDY] is it deemed to be ready for > inclusion. > > It would be great if github had a collaborative staging area, but > this seems like a good solution to me. > > On a similar vein, I've sometimes failed to get useful feedback on > specific implementations that are distinctly a work in progress, but > need feedback to proceed. Specifically, issue #68 in which I have > half of a complete implementation for that particular problem. It's > distinctly not PR ready, but is a WIP. I'm somewhat disinclined to > sink any more time into it without some further constructive > feedback, which I attempted to garner without much success. Interesting that you mention #68. That can hardly be seen as an example where it's difficult to engage me in discussions. The problem rather is, that several people seem unwilling to listen and unwilling to look at the broader perspective beyond their own pet feature. > I feel there is quite a bit that could be done very easily to make > contributors feel more welcome. A mechanism for better and more > patient code collaboration for WIPs would go a long way to this end. > Perhaps if Jan doesn't wish to be involved with this, a second mirror > repository on github could take on that role. If it's not clear: my goal is not to make contributors happy. It is to have users hate me less. In fact that should be obvious and the difference also. For every mediocre PR that I accept there will be 1 happy contributor and hunderds of users that hate me even more. Moreover, I have had very bad experiences in the past with would-be contributors whose self-confidence was much higher than their technological skills. In addition to no interest, I simply have no time for that anymore. That is a very important pratical limitation which everyone should simply respect. What MyHDL needs most in my opinion is not all kinds of new features. It is full of features that are underutilized and the most important contribution would be by users publishing about their work. No, what it needs is a better and more robust implementation. Even though jck has done a tremendous job in this in 0.9, I feel there is still a lot that can be done. Such "mundane" hard work gets my first priority and respect. As it now has come to the point when a contributor found it appropriate to insult me for not including his mediocre PR #101, I'd like to reconsider the whole labeling thing. I fear it may turn the PR area into a dumping ground on unfinished and dubious work. Like people that think they solve a problem by sending an email. I prefer not to play a role in that. I prefer the jck model of the past. Very hard work in the background, and then I get a PR that is obviously brilliant. Look at those PRs. They are by far the most complex contributions till now. Yet it didn't take me much time to pull them in. Jan > > Cheers, > > Henry > > > ------------------------------------------------------------------------------ > > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support > that you need to offload your IT needs and focus on growing your > business. Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > > > > _______________________________________________ myhdl-list mailing > list myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Henry G. <he...@ca...> - 2015-07-16 09:22:03
|
On 16/07/15 08:54, Jan Decaluwe wrote: >> On a similar vein, I've sometimes failed to get useful feedback on >> >specific implementations that are distinctly a work in progress, but >> >need feedback to proceed. Specifically, issue #68 in which I have >> >half of a complete implementation for that particular problem. It's >> >distinctly not PR ready, but is a WIP. I'm somewhat disinclined to >> >sink any more time into it without some further constructive >> >feedback, which I attempted to garner without much success. > Interesting that you mention #68. That can hardly be seen as an > example where it's difficult to engage me in discussions. The > problem rather is, that several people seem unwilling to listen > and unwilling to look at the broader perspective beyond their > own pet feature. The problem wasn't #68 per se, but rather there was no route to discuss the specific implementation. Now, whether you agree or not the problem is worth working on, there is clearly something that is irking people. Personally, I don't have much interest in solving #68 - I worked on it because I thought it was an interesting problem from a programming perspective. I stopped because the one response was a snarky comment from you about run time that I was fully aware of and disclosed and wasn't really what I was garnering feedback on (the run time issue was due to it being a wip and is easy to remove with a little effort). >> >I feel there is quite a bit that could be done very easily to make >> >contributors feel more welcome. A mechanism for better and more >> >patient code collaboration for WIPs would go a long way to this end. >> >Perhaps if Jan doesn't wish to be involved with this, a second mirror >> >repository on github could take on that role. > If it's not clear: my goal is not to make contributors happy. It > is to have users hate me less. In fact that should be obvious and > the difference also. > > For every mediocre PR that I accept there will be 1 happy contributor > and hunderds of users that hate me even more. > > Moreover, I have had very bad experiences in the past with would-be > contributors whose self-confidence was much higher than their > technological skills. In addition to no interest, I simply have no time for > that anymore. That is a very important pratical limitation which > everyone should simply respect. With respect Jan, you can't start out by assuming everyone is incompetent, and certainly it is the case that areas of competence are not always overlapping. E.g. being a python guru is useful even if the person knows nothing about HDL, assuming the skills can be directed appropriately - the other skills will be developed along the way. Even the soft skills, like good management of contributors would be a big plus to the project. This isn't Linux, with the huge commercial resources backing it and a small army of full time developers to raise the contributions bar. > > What MyHDL needs most in my opinion is not all kinds of new features. > It is full of features that are underutilized and the most important > contribution would be by users publishing about their work. No, > what it needs is a better and more robust implementation. Even though > jck has done a tremendous job in this in 0.9, I feel there is still > a lot that can be done. Such "mundane" hard work gets my first priority > and respect. I fully concur with the sentiment, but community building just doesn't happen like that. People take an interest and are motivated by their personal itch that needs scratching, and then they work on the bigger problems as they get sucked in. Perhaps you're not interested in building a community, but by your own admission you're short of time. > As it now has come to the point when a contributor found it appropriate > to insult me for not including his mediocre PR #101, I'd like to reconsider > the whole labeling thing. I fear it may turn the PR area into a dumping > ground on unfinished and dubious work. Like people that think they > solve a problem by sending an email. I prefer not to play a role in that. > > I prefer the jck model of the past. Very hard work in the background, and > then I get a PR that is obviously brilliant. Look at those PRs. They are by > far the most complex contributions till now. Yet it didn't take me > much time to pull them in. #101 is a good point to raise. I think jmgc should certainly have been more polite in what he wrote, but it's not like you've been carefully wordsmithing your criticism of him (or anyone else for that matter). If you're not willing to take on the burden of interacting on the level that is necessary, let others help you. Ruling with an iron fist is all good and well, but it rather requires you to engage fully (lest people fork or simply bugger off). Cheers, Henry |
From: Jose M. G. C. <ch...@gm...> - 2015-07-16 10:26:34
|
Dear Jan, First of all, let me apologize for my yesterday wording, it was rude. Second, I am sorry to say that what I said is still valid, now myhdl has new bugs. Finally let me put it clear, I did not insult you, I just answered in the same way you answer to me, and sincerely, it hurts. Best, Jose M. > El 16/7/2015, a las 11:21, Henry Gomersall <he...@ca...> escribió: > > On 16/07/15 08:54, Jan Decaluwe wrote: >>> On a similar vein, I've sometimes failed to get useful feedback on >>>> specific implementations that are distinctly a work in progress, but >>>> need feedback to proceed. Specifically, issue #68 in which I have >>>> half of a complete implementation for that particular problem. It's >>>> distinctly not PR ready, but is a WIP. I'm somewhat disinclined to >>>> sink any more time into it without some further constructive >>>> feedback, which I attempted to garner without much success. >> Interesting that you mention #68. That can hardly be seen as an >> example where it's difficult to engage me in discussions. The >> problem rather is, that several people seem unwilling to listen >> and unwilling to look at the broader perspective beyond their >> own pet feature. > > The problem wasn't #68 per se, but rather there was no route to discuss > the specific implementation. Now, whether you agree or not the problem > is worth working on, there is clearly something that is irking people. > Personally, I don't have much interest in solving #68 - I worked on it > because I thought it was an interesting problem from a programming > perspective. I stopped because the one response was a snarky comment > from you about run time that I was fully aware of and disclosed and > wasn't really what I was garnering feedback on (the run time issue was > due to it being a wip and is easy to remove with a little effort). > >>>> I feel there is quite a bit that could be done very easily to make >>>> contributors feel more welcome. A mechanism for better and more >>>> patient code collaboration for WIPs would go a long way to this end. >>>> Perhaps if Jan doesn't wish to be involved with this, a second mirror >>>> repository on github could take on that role. >> If it's not clear: my goal is not to make contributors happy. It >> is to have users hate me less. In fact that should be obvious and >> the difference also. >> >> For every mediocre PR that I accept there will be 1 happy contributor >> and hunderds of users that hate me even more. >> >> Moreover, I have had very bad experiences in the past with would-be >> contributors whose self-confidence was much higher than their >> technological skills. In addition to no interest, I simply have no time for >> that anymore. That is a very important pratical limitation which >> everyone should simply respect. > > With respect Jan, you can't start out by assuming everyone is > incompetent, and certainly it is the case that areas of competence are > not always overlapping. E.g. being a python guru is useful even if the > person knows nothing about HDL, assuming the skills can be directed > appropriately - the other skills will be developed along the way. > > Even the soft skills, like good management of contributors would be a > big plus to the project. This isn't Linux, with the huge commercial > resources backing it and a small army of full time developers to raise > the contributions bar. > >> >> What MyHDL needs most in my opinion is not all kinds of new features. >> It is full of features that are underutilized and the most important >> contribution would be by users publishing about their work. No, >> what it needs is a better and more robust implementation. Even though >> jck has done a tremendous job in this in 0.9, I feel there is still >> a lot that can be done. Such "mundane" hard work gets my first priority >> and respect. > I fully concur with the sentiment, but community building just doesn't > happen like that. People take an interest and are motivated by their > personal itch that needs scratching, and then they work on the bigger > problems as they get sucked in. > > Perhaps you're not interested in building a community, but by your own > admission you're short of time. > >> As it now has come to the point when a contributor found it appropriate >> to insult me for not including his mediocre PR #101, I'd like to reconsider >> the whole labeling thing. I fear it may turn the PR area into a dumping >> ground on unfinished and dubious work. Like people that think they >> solve a problem by sending an email. I prefer not to play a role in that. >> >> I prefer the jck model of the past. Very hard work in the background, and >> then I get a PR that is obviously brilliant. Look at those PRs. They are by >> far the most complex contributions till now. Yet it didn't take me >> much time to pull them in. > > #101 is a good point to raise. I think jmgc should certainly have been > more polite in what he wrote, but it's not like you've been carefully > wordsmithing your criticism of him (or anyone else for that matter). > > If you're not willing to take on the burden of interacting on the level > that is necessary, let others help you. Ruling with an iron fist is all > good and well, but it rather requires you to engage fully (lest people > fork or simply bugger off). > > Cheers, > > Henry > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Henry G. <he...@ca...> - 2015-07-16 10:34:27
|
On 16/07/15 08:54, Jan Decaluwe wrote: > For every mediocre PR that I accept there will be 1 happy contributor > and hunderds of users that hate me even more. Just on this point, you're rather drawing a false dichotomy. Of course you shouldn't accept bad PRs - I don't think anyone is suggesting you should. Rather, there needs to be a route by which bad PRs become good PRs, and that doesn't need to fall on you. Cheers, Henry |
From: Jan D. <ja...@ja...> - 2015-07-16 12:21:57
|
On 07/16/2015 12:34 PM, Henry Gomersall wrote: > On 16/07/15 08:54, Jan Decaluwe wrote: >> For every mediocre PR that I accept there will be 1 happy contributor >> and hunderds of users that hate me even more. > > Just on this point, you're rather drawing a false dichotomy. Of course > you shouldn't accept bad PRs - I don't think anyone is suggesting you > should. Rather, there needs to be a route by which bad PRs become good > PRs, and that doesn't need to fall on you. Who are you, that you think you have anything to say about the way I choose to run my own open source project? To those who are actually listening: the answer to the suggestion is (obviously) NO. Of course many people have better Python skills than me, and I hope to see contributions from them. But I can hardly be an obstacle there: they don't need my guidance, and as can be seen from my track record I have little problems to judge the quality and incorporate them readily. For all other PR's, that are related to HDL-oriented decisions, I still have to meet the first person that I would trust to decide on them. For anybody who delves in the history of MyHDL, it will be obvious why. I hope that is crystal clear. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Henry G. <he...@ca...> - 2015-07-16 12:34:11
|
On 16/07/15 13:21, Jan Decaluwe wrote: > On 07/16/2015 12:34 PM, Henry Gomersall wrote: >> > On 16/07/15 08:54, Jan Decaluwe wrote: >>> >> For every mediocre PR that I accept there will be 1 happy contributor >>> >> and hunderds of users that hate me even more. >> > >> > Just on this point, you're rather drawing a false dichotomy. Of course >> > you shouldn't accept bad PRs - I don't think anyone is suggesting you >> > should. Rather, there needs to be a route by which bad PRs become good >> > PRs, and that doesn't need to fall on you. > Who are you, that you think you have anything to say about > the way I choose to run my own open source project? > Come on Jan, don't be so damn precious. I'm trying to help and your response is distinctly confrontational. Of course you can run your repository however you want, I'm just pointing out that perhaps there are ways you could be more accommodating without compromising the quality. > To those who are actually listening: the answer to the > suggestion is (obviously) NO. > > Of course many people have better Python skills than me, > and I hope to see contributions from them. But I can > hardly be an obstacle there: they don't need my guidance, > and as can be seen from my track record I have little > problems to judge the quality and incorporate them readily. But this is the problem. Working on solutions in isolation is a very *bad* way to do development. Nobody who is truly competent would try to work like that unless they have to. Getting feedback through ongoing code reviews is distinctly best practice. Currently this is very hard with MyHDL. > > For all other PR's, that are related to HDL-oriented > decisions, I still have to meet the first person that > I would trust to decide on them. For anybody who delves > in the history of MyHDL, it will be obvious why. > > I hope that is crystal clear. Nobody is doubting your ability or authority when it comes to this stuff, simply that if you're not keen to take a proactive role in the refinement of PRs, other people can help with this. This isn't about pushing crap into the repository, but about ironing out the problems in pull requests before needing to bother you with them. Please take my emails as what they are - a sincere and honest attempt to refine the process of making MyHDL the best it can be. Genuine best wishes, Henry |