Gallio revival

[Kobus van der Merwe]

I suggest we continue on a new thread to discuss a plan for moving forward

There have been a number of valuable suggestions on the previous thread on how to correct the project's stagnation. Let's prioritize here what should be done first.

A few suggestions from my side:

• Source repository: Should we move to Git?
• New release? Or at least a roadmap to the next release
• Web site: New host?

Regards,

Kobus van der Merwe

[Justin Webster]

Good idea Kobus.

I think that a project road map is top of the list (and that is essentially what this thread is about :) ). Whether or not a new release should be one of the first things to be tackled is debatable. I'd lean towards 'no' at first unless there were some specific features or fixes that were critical.

In my view, the top priority should be to 'get our house in order'. Open source projects live or die based upon volunteer involvement, and therefore the impediments to involvement need to be minimized. In my work on the Gallio source, I found quite a few impediments both to my initial attempts to set up a development workspace, and also later during my efforts to actually modify and contribute to the source.

Therefore, I would propose that the top priorities should be (not necessarily in order):

• Establish a new (or repair the existing) core team, and clearly identify everyone's interests, responsibilities, etc.
  
• Get the CI build environment and process fixed/improved. Make sure that we are fully leveraging the benefits of CI and of the unit tests, etc. that are already a part of the Gallio/MbUnit source.
• I would also suggest that we do at least a brief review at some point of whether the current CC.NET system is the best go-forward option, or if maybe Jenkins might be a better alternative.
• As has been previously mentioned, one aspect of this task will be to find/establish new servers and infrastructure for the build process, Gallio.org website, etc.
  
• Improve the documentation and/or automation surrounding the setup/validation of private development work spaces, and of how to use them. (For example, make it clear how one should compile, test, document, and submit changes using a local development workspace, and make it easy to do so. As an example, when I was changing the MbUnit source at one point I ran into a bunch of problems related to getting the Icarus to compile and run my modified MbUnit code and unit tests.)
• IF after a review of the current process, it is determined by the core team that Git would be a better choice than SVN/Google Code, I'd have no problem in advocating a switch to Git. However, I wouldn't advocate moving off of SVN until we know why and how Git is going to benefit the project sufficiently to warrant all of the effort, user confusion, etc. that would result from such a switchover.
  
• Refactor the build process and decouple the various optional modules and plugins from the 'core' modules.
• Review the existing documentation, and establish a 'documentation roadmap' to address any deficiencies and obsolete content in the documentation.
• Specifically, I think for Gallio we need to do a much better job of documenting both how and why you would use Gallio with nUnit and/or msTest.
• For MbUnit, we need some specific feature comparisons between MbUnit and nUnit and msTest. Since Charlie has already expressed an interest in doing this as a joint MbUnit/nUnit effort, we should take him up on the offer.
  
• Clearly and effectively document the 'value proposition' of both Gallio and of MbUnit, with at least some comparison or contrast info to the 'competition'. I.e. Why should someone choose to use Gallio and/or MbUnit (instead of or in addition to) nUnit, etc.
• Gallio and MbUnit aren't 'for profit'. They exist to make the users' lives easier. If we as experts don't know (and/or can't clearly explain) how Gallio or MbUnit will make a user's work life easier (vs. adopting another tool or no tool at all), what chance will the user have of figuring out the answer for himself/herself? Or of actually achieving success in the adoption once the decision is made?
• I also think that the existing Gallio/MbUnit user community should be surveyed to help gather this information, and that the info should also be used to influence the project's road map.
  
• Review the status (e.g. maturity, stability, obsolescence, etc.) of the various plugins, and determine a go-forward plan for each one. For example, Gallio's integration with ReSharper has been an ongoing thorn in our side. I happen to be a huge fan of ReSharper myself, but if we can't figure out how to work with JetBrains to figure out a way to reduce the problems between Gallio and ReSharper we may have to reevaluate the way in which we are currently integrating with ReSharper. (Just as an example.)
• Review the existing issue backlog (i.e. bug fixes and enhancement requests) to help determine the timing, content, and priority of a subsequent Gallio/MbUnit 'feature releases'.
  

Those are just my own current views on next steps though. I definitely want to hear what everyone else feels are their own top priorities.

--
You received this message because you are subscribed to the Google Groups "gallio-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gallio-dev+...@googlegroups.com.
To post to this group, send email to galli...@googlegroups.com.
Visit this group at http://groups.google.com/group/gallio-dev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matthew Ellis]

Hi. I work at JetBrains, as an evangelist for plugins to the .net products. I've been following along this discussion from the start, and think it's great that the community want to revive it. We're definitely keeping an eye on what happens here - whenever we release a new version of ReSharper or dotCover, we get a number of questions about Gallio support (although, I have to admit, the number of requests have reduced as the project has slowed down). I've submitted patches to the project to fix some of the main issues with ReSharper integration, but I think they've stayed as just patches.

I'd like to offer whatever help I can, from technical support to helping out on the codebase. The current code for the ReSharper plugin needs a lot of love - if I remember rightly, it has #ifdef'd code for all ReSharper versions from 3.1 (9 versions!) which makes it very hard to maintain. It needs some judicious pruning and refactoring to get things back in order, and this is probably not worth starting until there is a better idea of where the main Gallio (or mbunit) project is going (e.g. should it be a Gallio test runner, or an mbunit runner?)

But we're interested in supporting the project, and will be following along.

Matt

[Charlie Poole]

Hi Justin and Everyone,

> For MbUnit, we need some specific feature comparisons between MbUnit and nUnit and msTest. Since Charlie has already expressed an interest in doing this as a joint MbUnit/nUnit effort, we should take him up on the offer.

http://nunit.org/blogs/?p=201

OK, I'm proposing a project to do that. I think the idea of collaborating on a feature comparison is pretty cool. AFAIK, nobody has done it before. If anyone would like to participate in creating the MbUnit part of this, please contact me.

I'll announce the site as soon as I have it set up.

Charlie

[Andrew Stopford]

Hi,

That will be interesting to see, I know that my own blog and that of Jeff Brown has a few posts about a much earlier comparison between the NUnit and MbUnit. I think that such a comparison may help to simplify some things, for example MbUnit has three different assert constructs. Some of this could be spun off to github to see what works and is supported and what is not. The Resharper code can also be re factored and simplified, as Matthew points out it is a massive PIA and has no need to support so many old Resharper versions (I it could do with a rewrite IMHO).

Andy

[Andrew Stopford]

Hi,

On a side note I know that Gallio is used by a few folks internally in their products, Redgate and Telerik for example. Not sure if we have any lurkers but would any of these folks be interested in funding the project so we can (for example) setup up a new web home?

Thanks

Andy

[Mike Kitchen]

Hi all, I work on .NET projects. Recently we have been using Gallio against a resonable sized project. I have 10 years of programming in C#, if I can help in any way please let me know to keep this great project alive.

 

Regards

 

Mike

[Kobus van der Merwe]

Hi everyone

My apologies, I was absent from this discussion for a while. As mentioned before, I will now be able to dedicate a small amount of time to Gallio on a daily basis.

Justin made some excellent points and the responses to his post also contains some valuable input. In particular:

• I agree that a road map and team should be our first priority.
• Charlie's idea for an open feature comparison is an excellent starting point
• It's very important to simplify the CI build and command line build process
  

There's lots more to do but Justin and Charlie's ideas will take some time to get started.

Regards,

Kobus vdm

[Justin Webster]

Just wanted to give a progress update to everyone:

I'm still trying to rearrange my work stuff to take a more active role in reviving Gallio, but don't yet know how much time I'll have to devote yet. I'll give an update as soon as I know more.

To Mike and any others who have expressed an interest in playing a more active role in Gallio development (and also for those that have kept such an interest silent :) ), thank you! If you want to get started right away, I encourage you to start familiarizing yourself with the project source code, and also to consciously decide which area(s) of the project interest you most. Since we don't have an 'active' project leader right now, coordinating the involvement of new participants is a bit difficult at the moment, but hopefully that will be addressed in the very near future.

Another 'first step' is to help get the nUnit/MbUnit (or MbUnit/nUnit, if you like) collaborative comparison completed. I feel that having such a comparison will not only be a big benefit to the .NET testing community, it will also help the leader of the Gallio/MbUnit project (whoever it may be) make some important decisions about the future directions and the roadmap of the project. Charlie and I have already had a fairly in depth discussion on the matter, and we both agree that it is also the first step between a closer collaboration (and a less competitive relationship) between the Gallio and nUnit projects and development communities.

So I encourage any interested in helping with that effort to do so.

Also, please continue to post any suggestions, ideas, or "I'll help" offers in this thread for the time being. Once we have a more official 'active project leader', I expect that we will expand the scope of this discussion in both the Gallio User and Dev groups. And also solicit more widespread feedback from both communities.

Thanks,

Justin