> 1. Build should be reproducible (other than timestamps and > other trivia) > > I'm not sure how you are handling strong naming in your > releases. If you have a signing key, we may want to find a > way to securely share the key. Perhaps have it gpg encrypted > for multiple private keys (Nicko, Ron and I?) and placed in > the SVN repo, so that any one of us could produce a bug fix > version. If we need to add a new person to the build > community, one of the current holders could decrypt and reencrypt.
The strong name key is a big issue. We strong name sign all release assemblies. Currently I hold the only copy of the key, a situation that I am not happy with. This means that identical builds cannot be produced by other committers. I believe that Apache iBatis.NET distributes its strong name private key with their build so that anyone may reproduce the build. I don't think that this is necessarily the best option for log4net. I am not aware of any Apache guidance on this specific issue. I think that our enterprise users do not expect our strong name key to be public. Only official releases of log4net require the official strong name key. Official releases must be authorised by the PMC. Perhaps there is a role for the PMC to hold the strong name key and distribute it to the release manager. I don't exactly know where the PMC can securely hold the key, other than doing as you suggest and storing encrypted versions of the file. Should this be in the log4net repository or perhaps in the committers repository? I should be able to encrypt the key file with Ron and Curt's public keys, so that only they can decrypt them. I think that I would need to create I file per person. > Reproducible builds will likely mean a pretty detailed list > of O/S and software versions used in the build should be > published. Ideally kept on a separate VM just used for > builds so that an inadvertent update doesn't tweak the > process. If we could get the build done using Mono, then you > could consider the VMWare Mono image at http:// > www.mono-project.com/Downloads as the build environment. Currently our release package includes builds for Mono 1, Mono 2, .NET 1.0, .NET 1.1, .NET 2.0, .NET CF 1.0, .NET CF 2.0, SSCLI 1.0, CLI 1.0. We won't have a build for .NET 3.0 as the framework libraries have not bee updated in this version (really just a marketing label rather than a release). We can build all these only on the Windows platform. I think that a VM may be the right way to go with respect to building a stable secure release environment, however we would run into licensing issues if I tried o share/distribute the VM image. > 2. Distribution files should be named apache-log4net-whatever.zip I think we nearly do this, just need to replace the word 'incubating' with 'apache'. > 3. NOTICE.txt and LICENSE.txt should be NOTICE and LICENSE > > I understand the motivation to put the .txt on the files, but > the ASL talks about NOTICE file. Ok, not much trouble. > 4. NOTICE and LICENSE should be in assemblies > > Since apache-log4cxx-whatever.dll is likely to be > redistributed separately from the entire package, it should > include the NOTICE and LICENSE file in the assembly. See > last item on http://www.apache.org/dev/release.html. This talks about distribution of raw artefacts, which we would like to avoid, but accept that it may happen if distributed outside of the ASF's control. We can embed the files as resources within the assemblies. I'm not sure how useful that will be in practice as individuals receiving the DLL file can easily argue that they did not know it contains a set of licensing resources. One other point here relates to the name of the DLL. Currently this is log4net.dll. We cannot change this without breaking backward compatibility. http://incubator.apache.org/guides/releasemanagement.html#best-practice- unique-names This section says that all release artefacts should have unique names, preferably prefixed with 'apache'. The last package we build (1.2.10) contains 15 different assemblies all called 'log4net.dll'. While this is confusing it seems to be the only way to maintain runtime compatibility between builds, which is essential if 3rd party DLLs are to link to log4net assemblies. > 5. Use Apache log4net in place of log4net where possible See above. We should check through our documentation to verify that we are doing this. > 6. Remove the incubator notices Yes. I see that Curt has now signed Ron's GPG key. I am in contact with David Reid and hope to get my key signed this month. Cheers, Nicko
