No subject

Sat Nov 26 22:11:05 UTC 2011

as strong as you might find in alternative tool suites. Take the Atlassian =
suite for example. With JIRA, svn, FishEye, Crucible and Confluence, you ha=
ve a fully integrated and coherent system that covers source code repositor=
y, issue tracking, code review and browsing, collaborative document/content=
 wiki. If you add Bamboo, you even get continuous integration support. Ther=
e's other stuff too. Now, I don't want to look like I'm pitching for a move=
 to Atlassian, but having used their tools in anger at my current employer,=
 I can only say that they seem like a very good fit for LSB's needs. My und=
erstanding is that that Atlassian also state that they potentially offer fr=
ee use for open source projects and I'd be surprised if they didn't extend =
this to the LSB. They even have a fully hosted solution, something that mig=
ht be seen as a positive in light of the events of the past year or so. Wit=
h offerings like these available, I find myself looking at what LSB is curr=
ently using and I can't ignore the feeling it gives me, that LSB is not kee=
ping up with modern tools, etc. I can fully appreciate all the practical re=
asons why things are as they are and the amount of work involved in making =
a switch. My main point here is that things like this leave a less than ste=
llar impression with people and it may be a contributor to the perception o=
f LSB not being relevant or up to date. It is certainly something that bugs=
 me whenever I have to interact with the existing tools (I don't even bothe=
r with bzr - got enough new tools to learn already).

I'm aware the above may evoke some fairly strong reactions in some. I'm mor=
e interested in discussions about what realistic options might be available=
 and how to move LSB forward to make it more successful. Any toes trodden o=
n were entirely unintentional. ;)

On 22/02/2012, at 9:28 AM, Wichmann, Mats D wrote:

This is a more general notice of something a few people know about already.=

Since we're not using a fully integrated "code hosting suite", there are so=
features that some projects use, that LSB doesn't have, and some that
maybe don't integrate all that well.   I don't know about solving the smoot=
integration issue; and I don't propose we move the project over to a hostin=
site - we were very happy many years ago to move away from Sourceforge
which had some major issues; we used Gforge briefly to smooth the transitio=
but eventually moved away from it too.  Sometimes there's something to be
said for using good apps in each space rather than expecting one suite to
do everything.  Whatever.

Anyway, this message is to say I've put up an experimental site for LSB cod=
reviews, when the situation arises where it's useful to do that. We usually=
attach patches to bugs, and that's fine, but they can be put up here as wel=
and viewed as side-by-side comparisons of old and patched version, and
each change chunk can be individually commented on as well as the patch
as a whole. It's only an experiment, and can happily be considered a throwa=
if we don't like it; if we do, we can deploy it more robustly in the LSB in=
The pilot is at<> - y=
ou can create your own account there
(if this were deployed "for real" it can be hooked into the LF LDAP infrast=
so you won't need to maintain a separate account).  You can request particu=
people to review patches if you want, and if we get a few more users, we ca=
set up reviewing groups and use those as well.

The limitation is that the code does have to be standard type patches.
Some of the LSB submissions are sql statements to update the DB, and those
don't work here, I know.  There's also a bzr plugin you need to install if =
going to create review-ready patches (all the plugin does is when you run a
"bzr diff" the "old" file will be marked with the bzr revision info rather =
than the
modification date as would usually be the case; this lets the program gener=
the full marked-up display correctly) - bzr-diff-revid.

Go ahead and play, if something comes up that would be useful to use this f=

lsb-discuss mailing list
lsb-discuss at<mailto:lsb-discuss at lists.linux-found=>

Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

Dr Craig Scott
Computational Software Engineering Team Leader, CSIRO (CMIS)
Melbourne, Australia

More information about the lsb-discuss mailing list