Closed CharliePoole closed 7 years ago
I added comments to help in reviewing. I don't plan to change this before we merge because it now matches the published wiki NUnit Vision page. We should merge it and then use it as the basis for further changes.
Should we have a principle on how long we support legacy versions of the .NET Framework?
Sounds good.
Guys, a question about how you want to do this procedurally.
I had asked to just copy over the existing Vision doc and then modify it, get comments, re-modify, etc.
Some of you (I think Rob and Chris) objected and asked for a PR just to do the move. I said OK, I'll do two PRs, one for the move one for editing.
I'm getting a lot of comments here that feel like they are intended to define the final version. That's OK but I do not think they should be implemented in this PR because you will then be changing what was already changed when we do the final version. You will loose sight of the base that is being modified and the changes that may need to be explained to users. Remember the existing Vision has been the bible of NUnit since around 2008.
Nevertheless, I'm happy (well willing) to do it in any way you want, but I'd like us to decide before I add any comments onto your comments.
PS I don't consider this a decision requiring a formal vote. I'll see what the consensus is and act on it. Copying a file into a folder != voting on a governance policy.
I thought we were going to just do a PR and merge as-is, then do edits, but was confused by your comments on how you wanted to change the document, so thought you wanted to edit it now. I am good either way.
@rprouse I don't know what "do a PR and merge as is" means. This PR, which says "Start of #10" contains no changes from what's already in the wiki. It is the first of two PRs. The second one was to have the changes.
[This two-PR process seems to me to be a bit silly, but it's what this committee - or two members anyway - asked for. FYI committees I have seen usually work that way... if some members want a strict process followed but others do not care, the stricter process is usually followed. That's what happened here. Thank goodness we don't have to work this way on our actual software!]
Anyway, this PR is to merge the text of an existing document from our wiki into the governance repo. It is unchanged except for a few refs to being on the wiki and the title. It needs to be approved or rejected. If rejected for reasons of process, I need to know what you want to do instead.
@jnm2 Yes, funny. Just not that funny, to me, right now. 😞
@CharliePoole I'm sorry. 😞 I'm not sure everyone was understanding each other in #10. I agree, acting on this PR's line comments in a second PR seems unwieldy. I don't care whether there are one or two PRs so long as no changes in the substance of the text are squashed into the commit initially moving the document over, so that the diff exists in this repo.
Since @rprouse and @ChrisMaddock are the ones that communicated to you that they wanted two PRs, I'll let them review first because they have a clearer idea what they're looking for in this PR.
@CharliePoole I stated above that I thought we were doing two PRs to do a straight merge with the first. I only wanted to do two PR's because master is locked and it is best if we don't push directly to master. I only added comments to this PR because you did first so I thought you wanted a response. To be honest, I don't really give a fuck and I am getting sick of this. NUnit has been running fine for several years now without all this process and ceremony. You feel it is necessary which is fine, but let's just do it.
I am going to back off for awhile. I am not interested in this petty bullshit and as you can tell it is pissing me off. I am only trying to be helpful, but you see to be misinterpreting everything I say. Issues and PRs are not the best way to communicate and context is often lost. That is clearly happening and I am sorry if I have not been making my intentions clear enough.
@rprouse You didn't give any reason for wanting two PRs - i.e. because master is locked. I took the reason to be a lack of trust. I apologize for the misunderstanding. In any case, I didn't complain at the time, but when you didn't approve it for merge and everyone else followed suit, I got annoyed and my tone no doubt showed it. However, unless somebody else does something, this PR can't move forward.
I'm not in love with all the process and ceremony either. I think you need to look at the writing process. I asked people some questions and wrote drafts. The drafts reflected what I was told - or at least what I thought I was told. I tried not to inject my own views. We had reviews. People told me to add or change stuff. Almost nobody told me to take anything out. Committee writing seems to work that way. If it's too much, someone could go through and simplify it.
Since I started this in public, I will try to close it off in public. I think we are all trying to do the right thing, but nerves are getting a bit frayed by the process. I am sorry for anything I have done to contribute to that. I think I need to say my piece though...
@CharliePoole it is not just this PR that is upsetting me, this is just the latest example. It seems like ever since @OsirisTerje and I changed our minds about the adapter release last fall, you have become frustrated with people not sticking with plans and it feels like whenever anyone does that, you respond in a very passive aggressive way. To me, you have been taking minor misunderstandings and expanding them into unneeded back and forth.
Another recent example is the debate over dropping or obsoleting AssetHelper
. I know you did work separating it out and I am sorry for that, but the amount of discussion it raised was more than the work involved. I don't care whether we drop it or move it, I just don't think we can do either in one release, we need to inform users and since 99% of developers who use NUnit probably don't even read the release notes, the best way to do so is to put it in their face by Obsoleting something even if it doesn't meet a strict definition of Obsolete.
As you stated in a separate email, I think the transition process has gone on two long and the resulting ambiguity has led the two of us to step on each others' toes causing these problems.
Let's push through this and get it done. I am fine with this vision document as is. I am also fine with the core team addressing any changes at a later date. We've been trying to get everything in place, but that isn't necessary right now. Let's just get done what needs to get done and move forward.
(Apologies Rob, our comments overlapped. I don't think I contradicted you too heavily!)
Start of #10
Looking at the doc on the wiki, I saw it was still worded as things we were planning to do in NUnit 3.0. I modified the wording and corrected a few errors.
If you wait an hour or so before reviewing this, I'll add annotations about where I would like to go with it.