Home » Archived » BIRT » BIRT release management is doing itself a disservice
| BIRT release management is doing itself a disservice [message #115727] |
Wed, 25 January 2006 09:36  |
Eclipse User |
|
|
|
Originally posted by: maspeli.deloitte.co.uk
Hi BIRT people,
I want to put this in writing, in the hope that you will learn from it. I'm
not trying to troll, only to offer my an insight into the experiences of
someone from outside your sphere trying to use BIRT.
First of all, I'm very impressed with the work you've done. BIRT is a huge
achievement, and to my knowledge there's nothing like it in the open source
world. I plan to advocate it to my peers, and I'm currently using it on an
important project with good results. BIRT is a big deal - it's had press
coverage e.g. in The Register and eWeek, it's starting to gain some
recognition.
Yet I wonder how many people have been driven to frustration by the quality
of the release process. For example:
- A release branded as Release Candidate (RC1) still had significant,
show-stopping bugs in it (for me, it was the chart engine not being able to
handle charts with parameters). The web viewer also still does not work with
Firefox 1.5, and this is not clearly pointed out anywhere that I can find.
And now, after upgrading from RC2 to 2.0 final, my PDF generation has
stopped working.
- It is hard to install BIRT (because there is no installer and you need to
manually find, fish out and move dependencies into the right place)
- The instructions on http://download.eclipse.org/birt/downloads/ are terse
and hidden among a lot of other text (the fact that the (old) general
eclipse web site design is terrible doesn't help you much, though I realise
this isn't your fault), and sometimes confusing (for example I don't need to
manually install the GEF or EMF, I can use Eclipse's updater). Oh, and the
front page says: "The current released version is 1.0.1.".
How many posts in this newsgroup have been about just that installation
procedure recently? How many people visit eclipse.org/birt and get confused?
Yes, I realise it's not hard when you know how it's done, but it *is* hard
the first time, especially when you don't have much time to read every word
on every page.
I'm heavily involved with another end-user oriented open source project, and
I know that release management is not easy at all. Someone needs to be
responsible for it, someone needs to put the foot down when a deadline slips
but the software still isn't in a good enough state. Based on my experiences
there, I cannot stress enough the importance of a few guiding principles:
- If a release is branded RC (Release Candidate) it damned well better be a
release candidate (i.e. something you think should be a release). RC
releases need to get the most testing of any release before they're tagged
and unleashed on the world, because people will typically judge the system
by these releases much more harshly than by a beta or milestone. Do you have
functional tests? Unit tests? I certainly hope so, and they need to be
vigorously maintained and run on every checkin.
- Make the software as easy to install as possible. I'm aware that you are
having political issues to get a proper bundle out there, but smart heads
like you should be able to find some way of making this easy. A fetch
script. An installer binary. An unofficial distribution. No matter how great
BIRT is, if I can't evaluate it, I'm going to give up on it.
- Put some effort into marketing your release on the website. Review the
literature properly before pushing out a final release and make sure that
those who read about BIRT in eWeek and did a google will find what they're
looking for - the latest, proper, stable release, with as little pain as
possible.
Ultimately, this serves one purpose: Get people using your software. The
most people use it, the more potential contributors you find, the more
positive press coverage you get, the more word-of-mouth marketing you get. I
know it's not easy, especially if your core contributors are coders and not
marketers, but given what BIRT is, and how big it ought to get, leaving
these issues to chance hardly seems a safe strategy.
I hope you'll take my comments for what they're intended - constructive
criticism. I have enormous respect for the work you've done, and I truly
want BIRT to succeed.
All the best,
Martin
|
|
| | | | | |
| Re: BIRT release management is doing itself a disservice [message #116250 is a reply to message #115866] |
Wed, 25 January 2006 13:33  |
| Eclipse User |
|
|
|
Originally posted by: pcasey.earthlink.net
I have to agree with the OP as well. The BIRT install experience is among
the worst I've ever encountered, and that's not hyperbole. 1.0.1 was very
awkward with a lot of steps, but I was willing to forgive a fair amount for
a 1.0 release. 2.0 though is even more awkward than 1.0.1, has more steps,
changes the way things worked in 1.0.1, and has the added benefit of being
actively documented wrong on at least one significant issue (the iText jar
version).
I'm glad somebody else took the time to write out a critique, because I was
feeling the same way but just couldn't find the time.
--- Pat
"Mark Lorenz" <mlorenz@nc.rr.com> wrote in message
news:426a5d4fb1d44155343233d0897a2a43$1@www.eclipse.org...
> As a battle-scarred BIRT user from 1.0.1 to today, I agree with much of
> what you say. To me, many issues could be solved by dealing with:
>
> "It is hard to install BIRT (because there is no installer and you need to
> manually find, fish out and move dependencies into the right place)"
>
> An installer that will install and upgrade BIRT successfully would solve a
> large percentage of the newsgroup questions and problems.
>
> I am an advocate of BIRT in my large organization, but it is difficult
> when you upgrade and many functions break. E.g., it took me 1/2 a week to
> figure out that I needed the newer version of the iText jar (which is
> *not* shown as the latest release on the iText site).
>
> BIRT is great. It would be even better if there was a production-quality
> installer.
>
> Mark
>
|
|
|
| Re: BIRT release management is doing itself a disservice [message #116822 is a reply to message #116250] |
Wed, 25 January 2006 15:57 |
| Eclipse User |
|
|
|
Originally posted by: doug_porter.dailyaccess.nospam.com
How would you recommend packaging the release to correct this problem? (Install for a webapp, install for eclipse RCP, option to
download dependent libraries...). Some brainstorming about how to best package things couldn't hurt.
Doug Porter
DailyAccess Corporation
"Patrick Casey" <pcasey@earthlink.net> wrote in message news:dr8ga2$j1s$1@utils.eclipse.org...
>
> I have to agree with the OP as well. The BIRT install experience is among
> the worst I've ever encountered, and that's not hyperbole. 1.0.1 was very
> awkward with a lot of steps, but I was willing to forgive a fair amount for
> a 1.0 release. 2.0 though is even more awkward than 1.0.1, has more steps,
> changes the way things worked in 1.0.1, and has the added benefit of being
> actively documented wrong on at least one significant issue (the iText jar
> version).
>
> I'm glad somebody else took the time to write out a critique, because I was
> feeling the same way but just couldn't find the time.
>
> --- Pat
>
> "Mark Lorenz" <mlorenz@nc.rr.com> wrote in message
> news:426a5d4fb1d44155343233d0897a2a43$1@www.eclipse.org...
> > As a battle-scarred BIRT user from 1.0.1 to today, I agree with much of
> > what you say. To me, many issues could be solved by dealing with:
> >
> > "It is hard to install BIRT (because there is no installer and you need to
> > manually find, fish out and move dependencies into the right place)"
> >
> > An installer that will install and upgrade BIRT successfully would solve a
> > large percentage of the newsgroup questions and problems.
> >
> > I am an advocate of BIRT in my large organization, but it is difficult
> > when you upgrade and many functions break. E.g., it took me 1/2 a week to
> > figure out that I needed the newer version of the iText jar (which is
> > *not* shown as the latest release on the iText site).
> >
> > BIRT is great. It would be even better if there was a production-quality
> > installer.
> >
> > Mark
> >
>
>
|
|
|
| Re: BIRT release management is doing itself a disservice [message #116924 is a reply to message #116822] |
Wed, 25 January 2006 22:39 |
| Eclipse User |
|
|
|
Originally posted by: pcasey.earthlink.net
I'd like it to install and just work. That was always the beauty of eclipse;
even if you couldn't figure out how to install a JVM and SWT to save your
life, you could just download the eclipse .zip (or .tar), unpack it, and run
eclipse.exe and it worked.
There's no one thing I can install though and make BIRT just work. Not only
does it require other eclipse dependencies (which aren't packaged with the
BIRT package), but it requires I pop off to two different third party sites
to get Apache and iText.
I'd like there to be just one .zip file that I could unpack into my eclipse
directory, restart eclipse, and then have BIRT show up.
As for the RTE: requiring that my web application replicate the eclipse
packages directory structure is, for lack of a better word, really funky.
Couldn't we just package the RTE as a .jar (or a collection of jars) and
configure it with a single .properties or .xml?
--- Pat
"Doug Porter" <doug_porter@dailyaccess.nospam.com> wrote in message
news:dr8omf$cg3$1@utils.eclipse.org...
> How would you recommend packaging the release to correct this problem?
> (Install for a webapp, install for eclipse RCP, option to
> download dependent libraries...). Some brainstorming about how to best
> package things couldn't hurt.
>
> Doug Porter
> DailyAccess Corporation
|
|
|
| Re: BIRT release management is doing itself a disservice [message #117093 is a reply to message #115866] |
Thu, 26 January 2006 03:33 |
| Eclipse User |
|
|
|
I suggested :
1) one script is provided to download all additional jars and copy them
under plugin.
2) or, one installer is provided, which contains Eclipse, GEF, EMF, and
BIRT. It download additional jars after normal installation and copy them
under plugin.
Cliff Liang
"Mark Lorenz" <mlorenz@nc.rr.com>
??????:426a5d4fb1d44155343233d0897a2a43$1@www.eclipse.org...
> As a battle-scarred BIRT user from 1.0.1 to today, I agree with much of
> what you say. To me, many issues could be solved by dealing with:
>
> "It is hard to install BIRT (because there is no installer and you need to
> manually find, fish out and move dependencies into the right place)"
>
> An installer that will install and upgrade BIRT successfully would solve a
> large percentage of the newsgroup questions and problems.
>
> I am an advocate of BIRT in my large organization, but it is difficult
> when you upgrade and many functions break. E.g., it took me 1/2 a week to
> figure out that I needed the newer version of the iText jar (which is
> *not* shown as the latest release on the iText site).
>
> BIRT is great. It would be even better if there was a production-quality
> installer.
>
> Mark
>
|
|
|
| Re: BIRT release management is doing itself a disservice [message #117239 is a reply to message #115727] |
Thu, 26 January 2006 06:23 |
| Eclipse User |
|
|
|
Hi,
thank you Martin for that post.
I have to agree, the installation procedure is somewhat cumbersome, but it
is manageable. I, too, am involved in an open source Eclipse project that
uses third-party libraries and I refrain from packaging it all together,
mainly to keep the download size small and because I don't want to have to
provide different download packages (one with the libs, another without).
Following a detailed description, anyone should be able to download two or
three libs and copy them to defined locations, although a script that does
the trick would be nice.
I have been using birt since version 1.0.1 and I think it is a great
product with a lot of potential.
I currently use it to provide a web app for the management department
where the 'bosses' can choose some parameters, mostly time periods, and
they get their reports generated.
But I have to say that I am fairly disappointed by the 2.0 release,
because there are still so many issues/features, even bugs, to be solved.
The main criticism and the reason for this post is about the release
management concerning the information on the website:
- On the project's main page, on Jan. 21st, it said that the 2.0 release
is out, but it took another 16 hours or so until the link in the download
section was available.
- Nowhere (afaik) did you mention that Firefox 1.5 is not supported. Had I
known this, I wouldn't have spent time upgrading my web app.
Here is another constructive criticism:
Martin is right when he says that people will be driven away when they
download birt, but can't find the help/information they need to run it on
the website. So, even if release dates are missed, you should take the
time to have the website up-to-date when the release comes out. It is
simply not a nice experience to download a new release and not be able to
use any turorials, help, how-tos, etc. provided on the website, because
they all refer to the last version.
Anyways, a big thank you to everybody involved. Keep up the good work.
Jan
|
|
|
| Re: BIRT release management is doing itself a disservice [message #117313 is a reply to message #116037] |
Thu, 26 January 2006 06:45 |
| Eclipse User |
|
|
|
Originally posted by: maspeli.deloitte.co.uk
Hi Jason,
First of all, even if you can't bundle the external code, that doesn't mean
you can't make it a bit easier. A download script would go a long way, as
would some unofficial bundle somewhere. The simple truth is that your
*users* don't care about the Eclipse politics, and it's making you look bad
for silly reasons. :) If I were release manager, I would've held the
software in an RC state until these issues could be resolved. The second you
call something a final release, expectations skyrocket, and the second those
expectations are not met, you reputation as a high-quality project is
tarnished. Bad press is hard to undo, and in this case probably unnecessary.
Perhaps I'm being overly paranoid here, but I've seen this go bad before,
and I'd hate for BIRT to get negative press for something not really related
to the quality of the product.
As for the website, you need to make this stupidly clear. You need to tell
people upfront:
- *Why* they have to jump through these hoops
- *Exactly* where they go to download the necessary libraries, preferably
with direct download links
- *Exactly* where each file goes, meaning the full path
- Instructions for Tomcat, JBOSS and standalone generation
- An explanation that birt.war is useless (why is it even in the .zip
file?)
This needs to be clearly laid out, not just put as plain text half way down
the page as it is currently.
In fact, I'd make this clear in the .zip as well. Add a README.txt to the
root of the runtime directory that explains how it all works. Rename Web
Viewer Examle to e.g. Web Viewer/birt and put another README in "Web
Viewer" there with all the instructions. And finally, at each location where
I'm supposed to put a dependency, put a marker .txt file with full
instructions on where to get it from, how to download it, how to extract it,
how to put it there.
Then *test* this procedure on someone who hasn't done it before. I realise
this is all a pain, but better you take the pain once than each user taking
the pain each time and coming to the forum with questions. :)
Thanks,
Martin
"Jason Weathersby" <jweathersby@actuate.com> wrote in message
news:dr87mi$23g$1@utils.eclipse.org...
> Martin/Mark,
>
> I want you to know that we appreciate your comments.
> I believe a single zip or installer would be great. Unfortunately,
> currently we
> can not do that because of license issues.
> All external code has to be approved by the foundation and this is a time
> consuming operation.
> This one particular issue has been discussed many times within the PMC and
> we are actively trying to solve it.
>
> We are also currently in the process of updating the web site to reflect
all
> changes for 2.0, so any comments you have on improving the
> install instructions are greatly appreciated.
>
> Jason
>
>
> "Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
> news:dr84o5$q9g$1@utils.eclipse.org...
> >
> >> I am an advocate of BIRT in my large organization, but it is difficult
> >> when you upgrade and many functions break. E.g., it took me 1/2 a week
> >> to
> >> figure out that I needed the newer version of the iText jar (which is
> >> *not* shown as the latest release on the iText site).
> >
> > Could you tell me what you did exactly? My PDFs have stopped working. :)
> >
> > Martin
> >
> >
>
>
|
|
|
| Re: BIRT release management is doing itself a disservice [message #117392 is a reply to message #117239] |
Thu, 26 January 2006 07:10 |
| Eclipse User |
|
|
|
Originally posted by: maspeli.deloitte.co.uk
"Jan Hendrik Scheufen" <jan-hendrik@gmx.net> wrote in message
news:b07991c4a1f886c053aec916113bd7d0$1@www.eclipse.org...
> Hi,
>
> thank you Martin for that post.
> I have to agree, the installation procedure is somewhat cumbersome, but it
> is manageable. I, too, am involved in an open source Eclipse project that
> uses third-party libraries and I refrain from packaging it all together,
> mainly to keep the download size small and because I don't want to have to
> provide different download packages (one with the libs, another without).
> Following a detailed description, anyone should be able to download two or
> three libs and copy them to defined locations, although a script that does
> the trick would be nice.
The only difference here is that BIRT is possibly pitched at slightly less
technical users. I certainly want to advocate it to people who would know a
bit of SQL, but not any Java. I think they can get good results out of BIRT,
especially where they are the less techncial member of a team.
Unfortunately, even just reading the instructions can scare people away. I
*know* it's not that hard, at least not when the instructions are correct,
but the fact is that a lot of people just don't have very much time for
trial-and-error when they want to try out BIRT. Say they had the choice
between BIRT and Crystal Reports. The uncertainty about even being able to
install it may make them plump for a Crystal license.
> I have been using birt since version 1.0.1 and I think it is a great
> product with a lot of potential.
> I currently use it to provide a web app for the management department
> where the 'bosses' can choose some parameters, mostly time periods, and
> they get their reports generated.
>
> But I have to say that I am fairly disappointed by the 2.0 release,
> because there are still so many issues/features, even bugs, to be solved.
> The main criticism and the reason for this post is about the release
> management concerning the information on the website:
>
> - On the project's main page, on Jan. 21st, it said that the 2.0 release
> is out, but it took another 16 hours or so until the link in the download
> section was available.
:-(
> - Nowhere (afaik) did you mention that Firefox 1.5 is not supported. Had I
> known this, I wouldn't have spent time upgrading my web app.
Agreed. This bug *still* gets me because I forget that I have to open IE to
view my reports (and I'm not interested in downgradin Firefox).
> Here is another constructive criticism:
> Martin is right when he says that people will be driven away when they
> download birt, but can't find the help/information they need to run it on
> the website. So, even if release dates are missed, you should take the
> time to have the website up-to-date when the release comes out. It is
> simply not a nice experience to download a new release and not be able to
> use any turorials, help, how-tos, etc. provided on the website, because
> they all refer to the last version.
It seems to me the release was driven more by some pre-set release dates
than by quality assurance processes. Open source release dates almost always
slip, which is unfortunate, but it's even less fortunate to call something a
final release when it's not ready. Is BIRT 2.0 ready now? Honestly, I don't
know, I haven't used it in anger yet. I know that RC1 wasn't ready to be an
RC1 and RC2 wasn't ready to be an RC2 (each had major bugs).
I have no time or interest in keeping up with Bugzilla to be able to assess
the quality of the software. A certain degree of trust is placed in the
release management team that when I download a release candidate, it's
something they think is release quality, and that the release candidates are
tested thoroughly enough that an actual *release* should be even more
stable. And as Jan Hendrik points out, the documentation and information
provided should keep up with the final releases, if nothing else. I
understand you may not be able to update all of it, but at least mark things
as being applicable to the old version, and have *something* up there
that's available for the new version.
All in all, does it matter whether the stable, usable version is called
2.0RC2 or 2.0 or 2.0.1 or 2.1 if it's going to take as long to fix it?
Actually, yes, because the next time around, I may be more cautious in
upgrading or recommending the software to others. Ultimately, users who feel
misled (obviously not deliberately, but that's moot) are less likely to come
back.
Martin
|
|
|
| Re: BIRT release management is doing itself a disservice [message #117405 is a reply to message #117313] |
Thu, 26 January 2006 07:12 |
| Eclipse User |
|
|
|
Martin,
Good comments all.
We do have a single click installer for BIRT at Actuate.com but I cant post
this in the news group.
Also it hasnt been updated for 2.0. This will be done in Feb.
That said, we have auto updating implemented in BIRT 2.0 and we are trying
come up with some scripts that
automatically look for the missing files and either download them or inform
the user to.
In the mean time Take a look at
http://www.eclipse.org/birt/phoenix/build/
I updated it last night. It is still convoluted to me.
Thanks
Jason
"Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
news:dracon$33i$1@utils.eclipse.org...
> Hi Jason,
>
> First of all, even if you can't bundle the external code, that doesn't
> mean
> you can't make it a bit easier. A download script would go a long way, as
> would some unofficial bundle somewhere. The simple truth is that your
> *users* don't care about the Eclipse politics, and it's making you look
> bad
> for silly reasons. :) If I were release manager, I would've held the
> software in an RC state until these issues could be resolved. The second
> you
> call something a final release, expectations skyrocket, and the second
> those
> expectations are not met, you reputation as a high-quality project is
> tarnished. Bad press is hard to undo, and in this case probably
> unnecessary.
> Perhaps I'm being overly paranoid here, but I've seen this go bad before,
> and I'd hate for BIRT to get negative press for something not really
> related
> to the quality of the product.
>
> As for the website, you need to make this stupidly clear. You need to tell
> people upfront:
>
> - *Why* they have to jump through these hoops
> - *Exactly* where they go to download the necessary libraries, preferably
> with direct download links
> - *Exactly* where each file goes, meaning the full path
> - Instructions for Tomcat, JBOSS and standalone generation
> - An explanation that birt.war is useless (why is it even in the .zip
> file?)
>
> This needs to be clearly laid out, not just put as plain text half way
> down
> the page as it is currently.
>
> In fact, I'd make this clear in the .zip as well. Add a README.txt to the
> root of the runtime directory that explains how it all works. Rename Web
> Viewer Examle to e.g. Web Viewer/birt and put another README in "Web
> Viewer" there with all the instructions. And finally, at each location
> where
> I'm supposed to put a dependency, put a marker .txt file with full
> instructions on where to get it from, how to download it, how to extract
> it,
> how to put it there.
>
> Then *test* this procedure on someone who hasn't done it before. I realise
> this is all a pain, but better you take the pain once than each user
> taking
> the pain each time and coming to the forum with questions. :)
>
> Thanks,
> Martin
>
> "Jason Weathersby" <jweathersby@actuate.com> wrote in message
> news:dr87mi$23g$1@utils.eclipse.org...
>> Martin/Mark,
>>
>> I want you to know that we appreciate your comments.
>> I believe a single zip or installer would be great. Unfortunately,
>> currently we
>> can not do that because of license issues.
>> All external code has to be approved by the foundation and this is a time
>> consuming operation.
>> This one particular issue has been discussed many times within the PMC
>> and
>> we are actively trying to solve it.
>>
>> We are also currently in the process of updating the web site to reflect
> all
>> changes for 2.0, so any comments you have on improving the
>> install instructions are greatly appreciated.
>>
>> Jason
>>
>>
>> "Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
>> news:dr84o5$q9g$1@utils.eclipse.org...
>> >
>> >> I am an advocate of BIRT in my large organization, but it is difficult
>> >> when you upgrade and many functions break. E.g., it took me 1/2 a
>> >> week
>> >> to
>> >> figure out that I needed the newer version of the iText jar (which is
>> >> *not* shown as the latest release on the iText site).
>> >
>> > Could you tell me what you did exactly? My PDFs have stopped working.
>> > :)
>> >
>> > Martin
>> >
>> >
>>
>>
>
>
|
|
| |
| Re: BIRT release management is doing itself a disservice [message #117542 is a reply to message #117405] |
Thu, 26 January 2006 10:14 |
| Eclipse User |
|
|
|
Originally posted by: maspeli.deloitte.co.uk
Hi Jason,
I'm glad you're working on this. A few suggestions below:
- Explain why there are so many steps - people will wonder, and come here
asking.
- To install GEF and EMF, it's easier to use the Eclipes updater. It's
better if you provide the steps to that, rather than for the manual install,
since the updater also takes care of the case where you already have it
installed and/or need to upgrade.
- Why isn't BIRT available in the eclipse updater, by the way?
- You should higlight file paths in the document (e.g. with <tt> tags) so
they don't get so easily lost in the text.
- Can you link to iText.jar directly?
- Some screenshots for the things going on in Eclipse would be useful
- Get rid of birt.war in the runtime download. It serves no purpose since
you have to extract it anyway, and it's likely to confuse people who are
used to just dropping the .war in. Also rename "Web Viewer Example" to
something else so it's more clear that you should use this to install it.
I'd suggest calling it Web Viewer\birt (i.e. have a subdirectory). See also
my previous points about READMEs everywhere. Not everyone will be able to
read the website when they need to install it.
- The flash video is a good idea. Why is it hidden at the bottom, though?
Cheers,
Martin
"Jason Weathersby" <jweathersby@actuate.com> wrote in message
news:draeah$5rs$1@utils.eclipse.org...
> Martin,
>
> Good comments all.
> We do have a single click installer for BIRT at Actuate.com but I cant
post
> this in the news group.
> Also it hasnt been updated for 2.0. This will be done in Feb.
> That said, we have auto updating implemented in BIRT 2.0 and we are trying
> come up with some scripts that
> automatically look for the missing files and either download them or
inform
> the user to.
> In the mean time Take a look at
> http://www.eclipse.org/birt/phoenix/build/
> I updated it last night. It is still convoluted to me.
>
> Thanks
>
> Jason
>
>
>
> "Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
> news:dracon$33i$1@utils.eclipse.org...
> > Hi Jason,
> >
> > First of all, even if you can't bundle the external code, that doesn't
> > mean
> > you can't make it a bit easier. A download script would go a long way,
as
> > would some unofficial bundle somewhere. The simple truth is that your
> > *users* don't care about the Eclipse politics, and it's making you look
> > bad
> > for silly reasons. :) If I were release manager, I would've held the
> > software in an RC state until these issues could be resolved. The second
> > you
> > call something a final release, expectations skyrocket, and the second
> > those
> > expectations are not met, you reputation as a high-quality project is
> > tarnished. Bad press is hard to undo, and in this case probably
> > unnecessary.
> > Perhaps I'm being overly paranoid here, but I've seen this go bad
before,
> > and I'd hate for BIRT to get negative press for something not really
> > related
> > to the quality of the product.
> >
> > As for the website, you need to make this stupidly clear. You need to
tell
> > people upfront:
> >
> > - *Why* they have to jump through these hoops
> > - *Exactly* where they go to download the necessary libraries,
preferably
> > with direct download links
> > - *Exactly* where each file goes, meaning the full path
> > - Instructions for Tomcat, JBOSS and standalone generation
> > - An explanation that birt.war is useless (why is it even in the .zip
> > file?)
> >
> > This needs to be clearly laid out, not just put as plain text half way
> > down
> > the page as it is currently.
> >
> > In fact, I'd make this clear in the .zip as well. Add a README.txt to
the
> > root of the runtime directory that explains how it all works. Rename Web
> > Viewer Examle to e.g. Web Viewer/birt and put another README in "Web
> > Viewer" there with all the instructions. And finally, at each location
> > where
> > I'm supposed to put a dependency, put a marker .txt file with full
> > instructions on where to get it from, how to download it, how to extract
> > it,
> > how to put it there.
> >
> > Then *test* this procedure on someone who hasn't done it before. I
realise
> > this is all a pain, but better you take the pain once than each user
> > taking
> > the pain each time and coming to the forum with questions. :)
> >
> > Thanks,
> > Martin
> >
> > "Jason Weathersby" <jweathersby@actuate.com> wrote in message
> > news:dr87mi$23g$1@utils.eclipse.org...
> >> Martin/Mark,
> >>
> >> I want you to know that we appreciate your comments.
> >> I believe a single zip or installer would be great. Unfortunately,
> >> currently we
> >> can not do that because of license issues.
> >> All external code has to be approved by the foundation and this is a
time
> >> consuming operation.
> >> This one particular issue has been discussed many times within the PMC
> >> and
> >> we are actively trying to solve it.
> >>
> >> We are also currently in the process of updating the web site to
reflect
> > all
> >> changes for 2.0, so any comments you have on improving the
> >> install instructions are greatly appreciated.
> >>
> >> Jason
> >>
> >>
> >> "Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
> >> news:dr84o5$q9g$1@utils.eclipse.org...
> >> >
> >> >> I am an advocate of BIRT in my large organization, but it is
difficult
> >> >> when you upgrade and many functions break. E.g., it took me 1/2 a
> >> >> week
> >> >> to
> >> >> figure out that I needed the newer version of the iText jar (which
is
> >> >> *not* shown as the latest release on the iText site).
> >> >
> >> > Could you tell me what you did exactly? My PDFs have stopped working.
> >> > :)
> >> >
> >> > Martin
> >> >
> >> >
> >>
> >>
> >
> >
>
>
|
|
| | |
| Re: BIRT release management is doing itself a disservice [message #117946 is a reply to message #115727] |
Thu, 26 January 2006 14:56 |
| Eclipse User |
|
|
|
I want to thank everyone for there feedback on this subject.
The PMC is currently working on some proposals to solve this issue.
Once that is complete, I will post for your feedback
Jason Weathersby
BIRT PMC
"Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
news:dr82d6$jht$1@utils.eclipse.org...
> Hi BIRT people,
>
> I want to put this in writing, in the hope that you will learn from it.
> I'm
> not trying to troll, only to offer my an insight into the experiences of
> someone from outside your sphere trying to use BIRT.
>
> First of all, I'm very impressed with the work you've done. BIRT is a huge
> achievement, and to my knowledge there's nothing like it in the open
> source
> world. I plan to advocate it to my peers, and I'm currently using it on an
> important project with good results. BIRT is a big deal - it's had press
> coverage e.g. in The Register and eWeek, it's starting to gain some
> recognition.
>
> Yet I wonder how many people have been driven to frustration by the
> quality
> of the release process. For example:
>
> - A release branded as Release Candidate (RC1) still had significant,
> show-stopping bugs in it (for me, it was the chart engine not being able
> to
> handle charts with parameters). The web viewer also still does not work
> with
> Firefox 1.5, and this is not clearly pointed out anywhere that I can find.
> And now, after upgrading from RC2 to 2.0 final, my PDF generation has
> stopped working.
>
> - It is hard to install BIRT (because there is no installer and you need
> to
> manually find, fish out and move dependencies into the right place)
>
> - The instructions on http://download.eclipse.org/birt/downloads/ are
> terse
> and hidden among a lot of other text (the fact that the (old) general
> eclipse web site design is terrible doesn't help you much, though I
> realise
> this isn't your fault), and sometimes confusing (for example I don't need
> to
> manually install the GEF or EMF, I can use Eclipse's updater). Oh, and the
> front page says: "The current released version is 1.0.1.".
>
> How many posts in this newsgroup have been about just that installation
> procedure recently? How many people visit eclipse.org/birt and get
> confused?
> Yes, I realise it's not hard when you know how it's done, but it *is* hard
> the first time, especially when you don't have much time to read every
> word
> on every page.
>
> I'm heavily involved with another end-user oriented open source project,
> and
> I know that release management is not easy at all. Someone needs to be
> responsible for it, someone needs to put the foot down when a deadline
> slips
> but the software still isn't in a good enough state. Based on my
> experiences
> there, I cannot stress enough the importance of a few guiding principles:
>
> - If a release is branded RC (Release Candidate) it damned well better be
> a
> release candidate (i.e. something you think should be a release). RC
> releases need to get the most testing of any release before they're tagged
> and unleashed on the world, because people will typically judge the system
> by these releases much more harshly than by a beta or milestone. Do you
> have
> functional tests? Unit tests? I certainly hope so, and they need to be
> vigorously maintained and run on every checkin.
>
> - Make the software as easy to install as possible. I'm aware that you are
> having political issues to get a proper bundle out there, but smart heads
> like you should be able to find some way of making this easy. A fetch
> script. An installer binary. An unofficial distribution. No matter how
> great
> BIRT is, if I can't evaluate it, I'm going to give up on it.
>
> - Put some effort into marketing your release on the website. Review the
> literature properly before pushing out a final release and make sure that
> those who read about BIRT in eWeek and did a google will find what they're
> looking for - the latest, proper, stable release, with as little pain as
> possible.
>
> Ultimately, this serves one purpose: Get people using your software. The
> most people use it, the more potential contributors you find, the more
> positive press coverage you get, the more word-of-mouth marketing you get.
> I
> know it's not easy, especially if your core contributors are coders and
> not
> marketers, but given what BIRT is, and how big it ought to get, leaving
> these issues to chance hardly seems a safe strategy.
>
> I hope you'll take my comments for what they're intended - constructive
> criticism. I have enormous respect for the work you've done, and I truly
> want BIRT to succeed.
>
> All the best,
> Martin
>
>
|
|
|
| Re: BIRT release management is doing itself a disservice [message #118165 is a reply to message #117946] |
Thu, 26 January 2006 17:33 |
| Eclipse User |
|
|
|
Originally posted by: jake.westviewclose.co.uk
Jason,
I'm a little bit late to the party on this, but mainly stayed out as I
don't really know my war from my jar.......
However, someone raised a very good point (apologies that I'm too lazy
to re-read all the posts to give credit directly...but you know who you
are.)
Basically they stressed that it was imperative that any guidelines you
put out should be "road-tested" by someone who had never used BIRT before.
I know that this is obvious, but I just wanted to mention that when I
first downloaded BIRT I had all sorts of problems. I basically ended up
copying every file into every location and finally hit upon the correct
solution. It took me about a full day before I could get it to work.
I've upgraded my development machine to 2.0 this week. Took about 2
minutes. It was easy. But that was because I know what I'm looking at
now. I know exactly what the plug-in file is. I know where the eclipse
directory is etc, etc.
It really is far to easy to think that an instruction is very explicit,
to then give it to someone who has no idea what they are looking at and
find out its just not quite clear enough. Whilst I'll be happy to give
feedback on anything, I now know how it hangs together. You need to dig
around for some people who don't know anything about BIRT. If they sail
through installation etc, then you've got it about right!
Apologies, this is all very "obvious", just wanted to re-iterate the point.
Jake
Jason Weathersby wrote:
> I want to thank everyone for there feedback on this subject.
> The PMC is currently working on some proposals to solve this issue.
> Once that is complete, I will post for your feedback
>
> Jason Weathersby
> BIRT PMC
>
>
> "Martin Aspeli" <maspeli@deloitte.co.uk> wrote in message
> news:dr82d6$jht$1@utils.eclipse.org...
>
>>Hi BIRT people,
>>
>>I want to put this in writing, in the hope that you will learn from it.
>>I'm
>>not trying to troll, only to offer my an insight into the experiences of
>>someone from outside your sphere trying to use BIRT.
>>
>>First of all, I'm very impressed with the work you've done. BIRT is a huge
>>achievement, and to my knowledge there's nothing like it in the open
>>source
>>world. I plan to advocate it to my peers, and I'm currently using it on an
>>important project with good results. BIRT is a big deal - it's had press
>>coverage e.g. in The Register and eWeek, it's starting to gain some
>>recognition.
>>
>>Yet I wonder how many people have been driven to frustration by the
>>quality
>>of the release process. For example:
>>
>>- A release branded as Release Candidate (RC1) still had significant,
>>show-stopping bugs in it (for me, it was the chart engine not being able
>>to
>>handle charts with parameters). The web viewer also still does not work
>>with
>>Firefox 1.5, and this is not clearly pointed out anywhere that I can find.
>>And now, after upgrading from RC2 to 2.0 final, my PDF generation has
>>stopped working.
>>
>>- It is hard to install BIRT (because there is no installer and you need
>>to
>>manually find, fish out and move dependencies into the right place)
>>
>>- The instructions on http://download.eclipse.org/birt/downloads/ are
>>terse
>>and hidden among a lot of other text (the fact that the (old) general
>>eclipse web site design is terrible doesn't help you much, though I
>>realise
>>this isn't your fault), and sometimes confusing (for example I don't need
>>to
>>manually install the GEF or EMF, I can use Eclipse's updater). Oh, and the
>>front page says: "The current released version is 1.0.1.".
>>
>>How many posts in this newsgroup have been about just that installation
>>procedure recently? How many people visit eclipse.org/birt and get
>>confused?
>>Yes, I realise it's not hard when you know how it's done, but it *is* hard
>>the first time, especially when you don't have much time to read every
>>word
>>on every page.
>>
>>I'm heavily involved with another end-user oriented open source project,
>>and
>>I know that release management is not easy at all. Someone needs to be
>>responsible for it, someone needs to put the foot down when a deadline
>>slips
>>but the software still isn't in a good enough state. Based on my
>>experiences
>>there, I cannot stress enough the importance of a few guiding principles:
>>
>>- If a release is branded RC (Release Candidate) it damned well better be
>>a
>>release candidate (i.e. something you think should be a release). RC
>>releases need to get the most testing of any release before they're tagged
>>and unleashed on the world, because people will typically judge the system
>>by these releases much more harshly than by a beta or milestone. Do you
>>have
>>functional tests? Unit tests? I certainly hope so, and they need to be
>>vigorously maintained and run on every checkin.
>>
>>- Make the software as easy to install as possible. I'm aware that you are
>>having political issues to get a proper bundle out there, but smart heads
>>like you should be able to find some way of making this easy. A fetch
>>script. An installer binary. An unofficial distribution. No matter how
>>great
>>BIRT is, if I can't evaluate it, I'm going to give up on it.
>>
>>- Put some effort into marketing your release on the website. Review the
>>literature properly before pushing out a final release and make sure that
>>those who read about BIRT in eWeek and did a google will find what they're
>>looking for - the latest, proper, stable release, with as little pain as
>>possible.
>>
>>Ultimately, this serves one purpose: Get people using your software. The
>>most people use it, the more potential contributors you find, the more
>>positive press coverage you get, the more word-of-mouth marketing you get.
>>I
>>know it's not easy, especially if your core contributors are coders and
>>not
>>marketers, but given what BIRT is, and how big it ought to get, leaving
>>these issues to chance hardly seems a safe strategy.
>>
>>I hope you'll take my comments for what they're intended - constructive
>>criticism. I have enormous respect for the work you've done, and I truly
>>want BIRT to succeed.
>>
>>All the best,
>>Martin
>>
>>
>
>
>
|
|
| | |
Goto Forum:
Current Time: Tue Jul 08 21:00:04 EDT 2025
Powered by FUDForum. Page generated in 0.09529 seconds |
Home