Hai,
Can u send me a java code which will create a new menu(not a replaced menu)
in openoffice components.since i am doing a project in which there is a need
to add a menu for some enchancements.please help me
--
Madhan
Hi,
right now, we have more than 20 open issues of type PATCH with target
2.0.4. Are you sure your patch can go into 2.0.4? Some issues can go there
(mainly simple l10n/translation issues) but some are simply unrealistic...
Please spend three minutes of your time today on cleaning your issues
madhan ponnusamy wrote:
Hai,
Can u send me a java code which will create a new menu(not a replaced
menu)
in openoffice components.since i am doing a project in which there is a
need
to add a menu for some enchancements.please help me
you should take a look to the simple add-on example in
Hi,
the P1 issue i67982, that was found on the milestone m179 of SRC680,
brought up the question whether there might be cases when it is useful
to re-open a milestone that has already been announced as ready for CWS
usage, in order to integrate a P1 bugfix. As this matter does not only
From: Jörg Jahnke [EMAIL PROTECTED]
Date: Wed, 02 Aug 2006 10:46:07 +0200
Hi,
I'll try to read this long e-mail completely in the evening again. But here
is my first idea:
_B) Wait with the ready for CWS usage announcement until QA approval_
Minor modification of this: after
madhan ponnusamy írta:
Hai,
Can u send me a java code which will create a new menu(not a replaced
menu)
in openoffice components.since i am doing a project in which there is
a need
to add a menu for some enchancements.please help me
Do you want to create package (for Package installer) or
Pavel Janík írta:
Hi,
after Kevin's decision to leave our project, lingucomponent is almost
dead.
In the past, before every release we realized that many P2 bugs assigned to
lingucomponent are not being handled properly because we do not have
developers actively working on this part of the
Hi,
regarding position _B) below: one should point out that the milestone
will be delayed for more than 2-3 days in case something is wrong with
the milestone. Creating a CWS, fixing the bug, rebuilding, repackaging,
doing again the automated tests can possibly delay the milestone by a
week
What is the official policy on how to decide if the issue type
for something you
are writing should be PATCH or ENHANCEMENT? If the work is part of a CWS
which
one should it be? What if the issue first has a patch attached but then that
patch gets
included into a CWS? What if you are fixing a bug
Hi Thomas,
A stream is always compressed before encrypting by the package
component. The checksum is generated based on the first 1024 bytes of
the compressed stream data using SHA1 algorithm ( if the stream is
smaller the whole stream is taken ). This is why it is named SHA1/1K.
Hope that
Hi Kai,
in most cases the type PATCH should only used for contribution from
developers which don't can't commit to CVS by theirselfes. Once a patch
got reviewed and accepted, the type should be changed to ENHANCEMENT or
FEATURE if this is the case.
Martin
Kai Backman wrote:
What is the
Hi,
_A) Reasons to always fix the issues on the next milestone_
-1 for this one.
I object because the _always_ is too strict. We had in the past
situations, where we did for a single platform or a build configuration
a fix, where a full rebuild for all platforms was not needed. Often
these
Mikhail Voitenko schreef:
A stream is always compressed before encrypting by the package
component. The checksum is generated based on the first 1024 bytes of
the compressed stream data using SHA1 algorithm ( if the stream is
smaller the whole stream is taken ). This is why it is named SHA1/1K.
Hi all,
_A) Reasons to always fix the issues on the next milestone_
After a milestone is announced on [EMAIL PROTECTED],
developers nearly immediately start working on that milestone, they
create childworkspaces or resync their existing CWS against it. For
doing so they rely on having the
Martin Hollmichel wrote:
Hi,
_A) Reasons to always fix the issues on the next milestone_
-1 for this one.
I object because the _always_ is too strict. We had in the past
situations, where we did for a single platform or a build configuration
a fix, where a full rebuild for all platforms
_A) Reasons to always fix the issues on the next milestone_
-1 for this one.
I object because the _always_ is too strict.
+1 from me because of a very simple reason:
I just believe in processes if they are defined and documented clear and
strictly.
I personally could not see any real
Ok, I think we have the same understanding on this, so I suggest the
wording:
Issues should always be fixed on the next milestones,
these leaves an exception open with mentioning it, the original
statement didn't left any roon for exception, that's the reason why I
objected,
Additionally I
While talking about exceptions: even a possible rule of marking single
milestones as not usable for accepting child workspaces needs
exceptions. For example, there are childworkspaces working on build
problems, code cleanup (license, remove obsolete files, ...), or CWS or
build related tools
18 matches
Mail list logo
