Apache Allura™

• assigned_to: Peter Hartmann

ASF guidelines seem to imply that NOTICE files should be placed alongside LICENSE. Whe have several of those - one in top directory and also some placed in individual package directories. Should we follow this scheme and add LICENSE files to the rest of distributable packages, or just retain single copies and include them when building tarball/egg?

Note that NOTICE and LICENSE files require annual date bumps, which is a little troublesome. But keeping just one of the former means that it will include copyright statements about all our codebase, which may be inadequate in context of single package distribution.

• labels: asf -->
• status: open --> in-progress

• labels: --> asf

Having one at the top level seems simplest to me, and I think will suffice for Apache procedures, since I think Apache official releases will be a tarball of the whole codebase.

If we want to release individual packages separately on PyPI, then having a LICENSE and NOTICE within each might be necessary. IMO we could defer that until we get to that point. There will be other complexities at that point too (interdependence of Allura and "core" tools like ForgeDiscussion and ForgeWiki).

For more clarification on Apache requirements we may need to take this to the mailing list, even the incubator general list possibly.

Uhm. Not meaning to overcomplicate things here - but why PyPI release can't be considered an Apache relase? Is Apache release supposed to contain all of codebase? That seems unlikely. One notable example is httpd project itself, which maintains several packages in it's codebase that are not part of main release: http://svn.apache.org/viewvc/httpd/

Perhaps time is of some consideration here, and you want to get Apache release quickly and not wait for all the work needed to make proper PyPI release. That's reasonable, but PyPI release will eventually be done (as per [#3905] anyway). So I think it's good to take it into consideration now :)

My understanding is that an official Apache release that is voted on, approved, gets PGP signatures etc, and placed on the Apache mirrors is always the code. Binaries and other packages of convenience are certainly made by projects, but aren't really "official". Pypi packages seem to me to fall into a similar category (even though they aren't binaries, they're still distributed separately). That said, they still should have proper legal files with them.

So... assuming an official release would have the whole codebase and Pypi packages would be one per package (each useful for different use-cases), it seems that we'd need LICENSE and NOTICE files at each level so that they're contained in both formats.

• status: in-progress --> open

Sorry about lack of reports lately. Part of my pc's ram has failed and while it's in warranty service, I can't hope to launch vm and do some necessary testing. Namely:

• ForgeGit/forgegit/tests/data/*/hooks/pre-rebase.sample files are added to every newly initiated git repo, but appear to be copyrighted nontheless. It would be good to check if removal won't trigger any hidden dependency on them being there.
• Allura/allura/lib/widgets/resources/js/jquery.tag.editor.js is licensed under Creative Commons - ShareAlike, which makes it incompatible with Apache License 2.0. Promising substitute is here, but I'd need to launch local instance to check where and how this js code is being used in the first place :)

After that what's left it applying license header to all files lacking copyright information and RAT testing. I've pushed any changes I've done in meantime. Either someone will pick up or I'll resume the work as soon as I can.

Nice work - very thorough! I've merged ph/4648 since it looks good to me, and the changes to the jquery.lightbox_me.js version seem to work just fine on our pages with lightboxes.

The sample git hooks aren't needed. I removed all of them and the tests still passed. That is on db/4648 if you want to merge it.

The tag editor is used editing labels on tickets, and few other places that use labels, like project categorization. I think it'll take a little work to switch to a different library, but the jquery tags input you referenced looks nice. I like how it works better than the current tag/label editor :)

See also [#5942] specifically for switching out the tag editor js.

• status: open --> in-progress

Now that [#5942] is merged, I think we're nearly done with all the updates from 3rd-party code right? db/4648 removes the copyright from sample git hooks. Do you want to merge that Peter?

Is it something that must be done ASAP? No problem on my part, but I know it'll take some time before this ticket will be done, anyways.

No, not urgent. Once this whole ticket is done, I think we'll have legal stuff cleared so we can do our first release in the Apache Incubator, which will be nice :)

• status: in-progress --> code-review

• QA: Tim Van Steenburgh

• status: code-review --> in-progress
• Milestone: forge-backlog --> forge-apr-19

Hey Peter, this looks good, but per the ML discussion can you also add a NOTICE file to the top-level dir?

• status: in-progress --> closed