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:

This actually still downloads dmake 4.12 but the main url:

now redirects to:

and /files is not listed nor is it resolvable.

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


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:
For additional commands, e-mail:

RE: [Discuss] Review and improve graphics memory handling

2015-06-16 Thread Kay Schenk
On Jun 8, 2015 8:46 AM, Dennis E. Hamilton

 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

 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 []
 Sent: Sunday, June 7, 2015 18:57
 Subject: Re: [Discuss] Review and improve graphics memory handling

 On 02/06/2015 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.


 To unsubscribe, e-mail:
 For additional commands, e-mail:

 To unsubscribe, e-mail:
 For additional commands, e-mail:

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 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.


To unsubscribe, e-mail:
For additional commands, e-mail: