Important Note

Topics: Developer Forum
Jan 3, 2007 at 4:39 AM
Hi guys,

Just a note to let you know that unless I say so, when I check code in, it is NOT ready for prime time. I work from two different computers during the day so I tend not to leave stuff checked out because it prevents me from continuing it on the other computer.

I will NEVER intentionally check in known build-breaking code, although the code sometimes not be functional.

I have looked carefully over the changes Jachym made/suggested in my first check in and I will be careful in future to mark my cmdlet classes as internal until I am ready for you guys to use/change/alter/fix/upgrade/improve them.


- Oisin
Jan 3, 2007 at 4:52 AM
Sounds good. I think in general that as a courtesy to the folks who are contributing their free time to this project, we should either A) contact them via email about suggested improvements to their code B) post a message on the developer forum or C) create a new work item if the issue is a bug.

What we shouldn't be doing is changing other developer's code while they are still working on it. I've been guilty of doing this in terms of coding standards tweaks which are mostly formatting and usually not significant. I'll try to refrain until the code is pronounced done or the dev appears to have abandoned it. Does that ever happen with open source software? :-)

After the code is pronounced done either by closuse of the associated work item, post on the dev forum or lack of activity by that developer then I think the agile practice of "nobody owns a piece of code and everybody can change anything" applies. But only after the developer is done with it.

I have personally learned a fair amount from changes/suggestions made to my code which I appreciate. However I also admit that at first it rubbed me the wrong way, especially in the case where I wasn't done and wasn't asking for help. We have a number of bright folks contributing to PSCX which I truly appreciate. A little courtesy can go a long way to keeping everyone happy. :-)
Jan 3, 2007 at 5:02 AM
I think we should also consider asking folks to review a cmdlet when it is done and provide feedback to the requesting dev (as opposed to making the changes directly) so that he/she can make the suggested changes. That would provide for a better learning experience for that dev.

If the changes are significant enough then I suggest that the reviewer code up their changes to the reviewee's cmdlet, save it to a shelveset and notify the dev to take a look at the shelveset. Jachym has done this before and I think it is a great way to make more, uh, signficant changes/suggestions. This way, again, the dev benefits in their learning by merging in the changes from the shelveset if they agree with those changes.
Jan 3, 2007 at 5:03 AM
OK last post on this for tonight. If nobody seriously disagrees with this in the next couple of days then I will add this to the developer's guide wiki page.
Jan 3, 2007 at 2:24 PM
Sounds good to me.

Jachym, please don't get me wrong - I really appreciate the aid, and I can see that you are way more experienced in cmdlets than I (and probably .net in general), but it's very jarring to come back into your "house" and find that everything has been "tidied" and you don't know where anything is. But don't let that stop you critiqueing anything I do - I really appreciate it and I can see that I can learn a great deal from you in the process.

PowerShell Providers are my forte so far, and I will be adapting my base provider code for PSCX and checking it in for people to use, alongside an example provider; this is once I get my initial release of the archive cmdlets out the door.

Cheers guys,

- Oisin

Jan 3, 2007 at 2:58 PM
I am sorry for messing with your code, Oisin. It looked quite complete, and it wasnt checked out anywhere, so I thought you are done with it for the moment.

I think we should never check in code which is not complete. The shelve sets are much better for this: you can access them from any machine you work on, but you dont pollute the trunk with code which does not meet the PSCX standards yet. (for example the Write-Tar, which looks like some console application wrapped in a cmdlet class)
Jan 3, 2007 at 3:22 PM
Yes, the tar cmdlet is nowhere near done, that console class is just in there for reference so I can use it later. I agree it shouldn't be in there, but I don't know how else to make it available for myself on my other machines. So if there's a better way -- e.g. these "shelve sets" -- please let me know how to use this feature; I'd really appreciate it.

Just so you know, I know absolutely zero about TFS. It's a 200MB+ download, and intimidating. I've only ever worked with rcs, cvs, p4 and sourcesafe.

- Oisin
Jan 3, 2007 at 3:45 PM
OK, I've found some documentation on shelving -- so I will use that from now on. This is completely new to me.

Again, have patience please. This is an open project with people giving their free time. Some of us have more free time than others.

Thanks for the information.

- Oisin
Jan 3, 2007 at 3:50 PM
i've removed the reference code from WriteTarCommand, and checked in the clean file again.

- Oisin
Jan 3, 2007 at 6:33 PM
>> I think we should never check in code which is not complete.

That's a bit too black and white for me. Although I do believe that you should never checkin code that doesn't compile. Whether you check code into the trunk depends on a lot of factors. If I'm working on refactoring something that is essentially already done, I might do several intermediate checkins to preserve my work and more importantly different approaches to the refactoring.

I think if you feel confident that you can get a feature implemented by the time we plan to ship a new version then go ahead and checkin on trunk and checkin as frequently as you feel necessary.

If there is a question about whether or not it can be completed then a private branch would be better. Besides even stuff on trunk can be marked internal if it isn't ready for a release.