dmake location question?

2015-06-16 Thread Kay Schenk 
Hello all--

I'm in the process of redoing my OS, and wanted to reinstall dmake
locally which I had done before.

OK, here's out url ref:
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2

This actually still downloads dmake 4.12 but the main url:
http://dmake.apache-extras.org.codespot.com

now redirects to: https://github.com/mohawk2/dmake

and /files is not listed nor is it resolvable.

So, can someone fill us in on what is happening here?
-- 

MzK

We can all sleep easy at night knowing that
 somewhere at any given time,
 the Foo Fighters are out there fighting Foo.
  -- David Letterman

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [Discuss] Review and improve graphics memory handling

2015-06-16 Thread Kay Schenk 
On Jun 8, 2015 8:46 AM, Dennis E. Hamilton dennis.hamil...@acm.org
wrote:

 I've never understood this business of having multiple releases as
progressions on the same code branch.

 It seems far more confusing than having a branch or tag that corresponds
to the release identifier.

Actually before 4.1.1, we did use tags if memory serves. I just assumed
we could do this again for 4.1.2 unless there was some reason not to.

I also find the revision cut used for 4.1.1 confusing. In reality, we could
do a tag for it I think.

  It also helps if there is a need for a patch release at a particular
branch.

 It also makes check-out of a specific release branch easier.  And it is
easy to confirm the archive of the released source against its SVN.

 Although there is a lot of code involved, I thought SVN used a Copy on
Write strategy so copying code into a branch does not create actual copies
but links, with copies made only when a difference is introduced at either
end of the link.  Am I mistaken?

 I don't have much skin in this game.  It just strikes me that there is a
high risk of confusion and possible error this way.  Even if a 412 is built
from a copy of 411, rather than the trunk, with changes then cherry-picked
into it, it seems easier to inspect and to understand.

  - Dennis

 -Original Message-
 From: Andrea Pescetti [mailto:pesce...@apache.org]
 Sent: Sunday, June 7, 2015 18:57
 To: dev@openoffice.apache.org
 Subject: Re: [Discuss] Review and improve graphics memory handling

 On 02/06/2015 armin.le.gr...@me.com wrote:
  AFAIU AOO410 branch goes on for 411, 412, 413... versions. One branch
  for next mid-number change, e.g. AOO420 would need a new one. For AOO411
  we have no extra branch AFAIK, only a revision number in AOO410 branch.
  I would keep that schema - the goal of micro releases is minor
  changes/stability, no need for a new branch

 I'm OK with this. I will commit changes to the existing AOO410 branch
 instead of creating AOO412 then.

 Regards,
Andrea.

 -
 To unsubscribe, e-mail: 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

Re: [RAT REPORT] - 30 files with an unknown or no License Header

2015-06-16 Thread Jürgen Schmidt 
On 11/06/15 18:23, jan i wrote:
 On 8 June 2015 at 16:58, Regina Henschel rb.hensc...@t-online.de wrote:
 
 Hi Jürgen,

 is it OK to commit the patch?

 if it not ok to commit the patch, then I wonder how the files was committed
 in the first place.
 
 If it is not ok, then the files should be deleted. We cannot have files in
 trunk without the proper
 ALv2 license.
 
 Furthermore we cannot make a release with these files.
 
 I recommend applying the patch. Deleting the files might have sideeffects.
 

No it have no sideeffect and yes it is ok to apply the patch. As I
explained before these files are part of the started but currently
stopped new OOXML framework. It's part of the parser generator ...

Anyway it is a eclipse project in Java and the license headers were
simply forgotten in the first shot. If you want a Java tooling that
would have created C++ stubs and parser for doing the ground work for
OOXML parsing ...

Again these files should not be part of y source release and can be
filtered out as some other things as well.

Applying the patch and adding the license header is even better and more
clean for future purpose.

Juergen


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org