On 9 May 2013 14:40, Rob Weir <robw...@apache.org> wrote:
> On Thu, May 9, 2013 at 5:05 AM, janI <j...@apache.org> wrote:
> > On 9 May 2013 09:07, Andrea Pescetti <pesce...@apache.org> wrote:
> >
> >> janI wrote:
> >>
> >>> On 9 May 2013 00:23, Rob Weir wrote:
> >>>
> >>>> 5) Development is also made more difficult by the intrinsic complexity
> >>>> of the code base, the build system and the poor state of the developer
> >>>> documentation.
> >>>>
> >>> yes because we try to tell people to grasp the whole system in one-go
> >>>
> >>> "start by build AOO", that is a nice way of making a developer feel
> >>> insecure.
> >>>
> >>
> >> What can be done to improve this? Building OpenOffice is the first step
> >> for any core code contributor, I can't understand why this makes people
> >> feel insecure. But it's a critical point, so whatever we can do to
> improve
> >> this stage will help.
> >>
> > I think rob have a number of valid points, that we need better
> > documentation and a better build system, but this is a "devils circle",
> we
> > need it to keep committers and do have enough resources to do it over
> > night....IMHO we need to take an alternative path.
> >
> >>
> >> For example, impatient people who do not use "./configure --help" will
> >> have a hard time figuring out the errors with dmake and epm, and
> >> downloading the prebuilt unowinreg from http://www.openoffice.org/**
> >> tools/unowinreg_prebuild/<
> http://www.openoffice.org/tools/unowinreg_prebuild/>could be simplified
> or automated... But none of this seems a tremendous
> >> improvement to me. Can we do better? Does
> >> http://wiki.openoffice.org/**wiki/Documentation/Building_**Guide_AOO<
> http://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO>
> >> need some rewriting?
> >
> >
> > That building guide, can be seen as a guideline...it needs updating to a
> > much more precise step-by-step guide...no guessing follow this.
> > (I had f.x. to talk with arist to get a danish language built, configure
> > --help did not really help).
> >
> > I think there are 2 points that would really help newcommers or lower the
> > ladder:
> >
> > 1) provides a zip / tgz files with a preconfiguration and maybe a simple
> > setup.bat / setup.sh for the main platforms:
> > ubtuntu, windows
> >
> > 2) Provide a big zip / tgz file, with a copy of a built AOO (including .o
> > etc), with a simple instruction "it must be installed in directory x with
> > your own user"
> >
>
> I've had some parallel thoughts as well. Maybe even provide a VM with
> a complete Linux AOO dev environment already set up.
>
That is a real good idea...based on virtualbox, sadly enough we cannot do
the same with windows or is there a way around the license issue ?
>
> A script, of course, would be smaller but needs to deal with more
> platform differences.
>
> I like your idea better ! when we provide the vm we could of course easy
make a tar ball with the sources.
However we need to find a just as easy solution for windows users ?
>
> > I have done number 2) for a couple of friends, and they were happely up
> and
> > running in an hour.
> >
> > I am very well aware this is NO mid-term solution, but only a fast fix to
> > the problem at hand.
> >
>
> It might make sense to make a list: What are all the things that a
> new dev volunteer needs to know or do before they can make their first
> patch?
>
+1
>
> 1) What knowledge do we assume as a pre-req? Obviously we cannot
> tutor them in C++. But what else is an absolute prerequisite?
>
With the current build system, they need to have fundamental knowledge of:
- makefiles (we can provide a link, maybe it could be put in the
"introduction" course
- scripting languages (again with can provide links to documents)
2) Of the other items the need to know, what is already written down?
> I bet a lot of it already exits, but it is scattered about and/or
> out-of-date.
>
That is a bet I will not take, here is my list (what I missed, regina
described most of it in an earlier mail):
- a strict platfom related step-by-step build guide, with the variations
(debug for a single module, language version, normal build)
- An overview of our directory structure, with a short explanation what
is this directory containing
- An overview seen from the product e.g. writer consist of.
- helper tools
- Debug guide, how to do partial debugging (platform dependent), advice
on inspecting our objects (especially strings)
- Build guides pr. platform, with advice on rebuilding, especially if
with different configure (e.g. with/without language)
- short introduction to how we use svn (git?) and how to submit patches
(svn diff)
- A list of, at least but not limited to, pmc members and their field of
expertice, so a new person feels he/she knows us.
(actually such a list, helps a lot with the other missings)
I have one wild idea, which I do not know if it is can be done....extend
the introduction module with one lesson "solve your first bug", where we
make a step-by-step guide for solving a "real" bug, the idea is that the
developer can use it as a "template" to solve real bugs. This guide should
problaly come in 2 versions windows/linux.
> 3) Create a new index page (or update an existing one) to bring
> together links to all this information.
>
+1
>
> 4) Where needed update this information
>
+1
>
> 5) Set up a feedback mechanism so new developers can point out
> information that is not accurate or confusing. We could do this
> ourselves to some extent, by pretending we're new and following the
> instructions literally.
>
How about extending that to a survey....I have been thinking about that for
the introduction modules as well ?
Somewhere we also need to "define" and explain what a mentor does (and do
not do).
rgds
jan I.
>
>
> Regards,
>
> -Rob
>
> >
> >
> >>
> >> What we need to do (in my opinion) is to define small tasks
> >>> (preferable "hot" topics), not solve a bug (remember an office system
> is
> >>> not really "hot" for developers, and solving bugs is boring.
> >>>
> >>
> >> The "hotness" concept is correct. For example, a key feature of
> OpenOffice
> >> 4 is the sidebar; it may well be one of the "hot" developments you
> >> describe. So far it has been developed in a branch, with no public
> >> communication, then moved to trunk, again with no public communication,
> >> then subject to QA (again, no public communication except for mailing
> >> lists).
> >>
> >
> > The side bar might very well be a challenge, please remember for many
> > developer "hot" means an intelectual challenge, and something they can
> show
> > friends.
> >
> > Doing something like GSoC descriptions might very well be time well
> spent.
> >
> >
> >>
> >> If we identified 3-5 small development tasks to make the sidebar better
> or
> >> fix the discovered bugs, and exposed them in a blog post, we could
> >> (realistically) attract 3-5 new developers. But the trade-off would be
> that
> >> Andre, or some other expert developer, must spend time on mentoring new
> >> developers instead of making the fixes himself, which would probably
> take
> >> him less time. And those developers would need to work on less
> documented
> >> (since they are evolving) features, so this is feasible only if an
> >> experience developer is willing to invest a lot of time on it, as an
> >> investment to get more developers and better documentation.
> >>
> >
> > Look at it as an investment, spending time now getting others started,
> > ensures that we in mid-term have more helping hands.
> >
> > I will happely also identify 2-3 tasks in l10ntools, likewise maybe
> someone
> > could mentor (helping with templates and cmd) a new web design.
> >
> > If we dare, we could use rejuvenate01 (I really start to like the name),
> to
> > make a call for skilled system builders...saying we are starting a little
> > team to reinvent the infrastructure of AOO. Correctly formulated and put
> on
> > the right places, this could very well attract skilled makefile people
> who
> > would see it as a challenge (and be proud of) rejuenating that part. If
> we
> > do that, I would gladly be flag leader/mentor with the help of the
> > community.
> >
> > Ps. it is not bugs, but product enhancements....bugs is something very
> > boring, finding problems in other peoples code it not very fun.
> >
> >
> >
> >>
> >> people.apache.org/~jani/**topCommit6mdr.txt<
> http://people.apache.org/~jani/topCommit6mdr.txt>
> >>> people.apache.org/~jani/**topCommit1year.txt<
> http://people.apache.org/~jani/topCommit1year.txt>
> >>> people.apache.org/~jani/**topCommit2year.txt<
> http://people.apache.org/~jani/topCommit2year.txt>
> >>>
> >>
> >> Before we see direct links to these resources appearing everywhere and
> >> purported as official published statistics from the project, I'd
> recommend
> >> putting the URL of this discussion (from markmail or mail-archive) in
> the
> >> files, so people can get your accompanying explanation and the
> follow-up.
> >> As you say, it's always dangerous to interpret numbers... but it's also
> >> very easy to play with numbers, so explanations are always needed when
> >> presenting numbers.
> >>
> >
> > UPS !! my fault !!! sorry about that....it is corrected, please look and
> > see if the disclaimer fits the bill.
> >
> > Looking at the numbers again (80 (2 years) -> 58 (1year) -> 26 (this
> > year)), I cannot judge if people are just taking a break enjoying real
> > life, or if it signals people stopping working. I think it would be worth
> > while to investigate that part as well, and depending on the result take
> > some proper action. My problem is that I have not a clue to how to do
> such
> > an investigation.
> >
> > Thanks for all the positive feedback from both rob and andrea.
> >
> > rgds
> > jan I.
> >
> >>
> >> Regards,
> >> Andrea.
> >>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> dev-unsubscr...@openoffice.apache.org>
> >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
