What is thew future of Smart?

[rehan khan]

So after spending some considerable time with the Smart project over the past few weeks I find that Smart has some limitations with its future development. This is based on a couple of discussions on IRC regarding pending bug fixes and new features and the considerable backlog in the bug list.
 
It appears that obvious simple fixes cannot be applied because it might break backwards compatibility. This is not an unreasonable issue. However my experience with other projects and open source in general suggest there are acceptable ways forward in situations like this. A very simple example is the smart channel --show-penalities command, another is smart's usage of stdout/stderr, and another is the usage of the --dump option. Obvious ways forward with these issues is to make the correction and run the previous behaviour in parallel. This is quite difficult with the stdout/stderr issue but very simple with the --show-penalities and --dump commands. With --show-penalities we can add a --show-penalties option which does exactly the same thing and make a note in the change log that --show-penalities is deprecated and will be removed at milestone <X> and the same with the --dump option, we should run the --dump option in parallel with a new --show option for a couple of milestones with a note made in the change log that --dump will be deprecated by milestone <X> or --dump will change it's behaviour to be more debug oriented. Making these notes in the change log and ensuring that the community is aware of these changes should allow people to update their scripts to use the newer commands. Really, for the user it is just a grep -R "<whatever> <myscripts>, then make the changes, test, verify and move on.
 
Now we shouldn't dwell on the nitty-gritty of the actual changes, these are mentioned to give an idea of the issue. However we should focus on the much bigger issue of whether smart's feature set is fixed and if not to what extent it is changeable. Conventionally an Open Source project that achieves a 1.0 version is considered stable. Dramatically new features or refactored code then go into the 2.0 branch and the 1.0 branch goes into bug fix mode. With Smart this is not the case. The version is at 0.52 which suggests that the feature set is not stable and that users should expect changes in behaviour and clearly, to pay attention to the change log (err.... we should publish a change log with each release).
 
If the feature set is going to be fixed then the next release should be bumped up to 1.0 and only have bug fixes applied and new features should go into a 2.0 branch.
 
An associated issue is user requests. After trawling through around 200 issues in the old bug tracker and migrating about 140 to Launchpad Bugs I have seen many user requests that make a lot of sense (in fact if they didn't make sense they wouldn't have got into Launchpad bugs). The project team should take these requests much more seriously. Personally I don't file reports for every issue I come across using open source projects. However when I do, I usually feel strongly about the report, in fact so strongly that I take the time to make the report. If we don't respond positively to people who take the time and make the effort to communicate with us then they will go to other projects that will listen to their requirements. Implementing these things may take more time than is available and so may be put on hold (until some future milestone) but a note should be made about this and the reporter notified. If we are lucky the reporter might then actually make time to look at the code and submit a patch or a feature so that it gets in quicker.
 
I suspect that some of these issues are related to the fact that Smart is used in Landscape and changes need to be carefully made so as not to break Landscape. In that case then Landscape needs to be the upstream of Smart. If Landscape is not the upstream of Smart and Smart is indeed an independent project that has the freedom to respond to its user base, then Landscape bzr branches should be in their own sub-project ideally and Landscape's Smart version should track changes in Smart as it's upstream. Smarts relationship to Landscape should be made much clearer if Smart is tied to Landscape's requirements. 
 
Without due consideration of these issues I don't believe Smart has a way forward. It just cannot grow with users needs in a sensible way.

R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.labix.org/pipermail/smart-labix.org/attachments/20080726/3198cf7d/attachment-0002.htm>