Category Archives: Project

Filesender Workshop: Join us in Utrecht

Filesender will be hosting a two day workshop on 1st and 2nd May 2018 at the Surfnet Office in Utrecht.  The meeting is free to attend and registration is open.

This meeting will be a chance to meet the current lead developer for Filesender (Ben Martin).

The current plan is to make the 1st of May a day of discussion about FileSender which may include tips and tricks, what might be stopping deployments from moving to running the version 2.0 beta, desires for the future, and also some discussion on how we might handle issue reporting, tracking, and resolution; if github issues are where people should focus or if other methods might be better.

An optional hackathon is planned for the 2nd of May. This may just be a day more for the folks who like the nuts and bolts of the code than on the 1st. This could include all sorts of information ranging from how we might like to restructure parts of the code in the future through to how to create and make a pull request. There is also a potential discussion on how we might like to handle themes in the future. Maybe bootstrap is an interesting migration target for the UI? Database abstraction is another good open topic, though there are no shortage of things that can be discussed for interested programmers.

We’d love to hear your ideas and thoughts as to what should be included in the programme.  Please sign-up to the mailing lists or drop us a line.

Filesender Future Directions at TNC17 BoF

Thanks to all of of you that joined the Filesender Board for the BoF at TNC this year.   The slides presented by Jan are available and we appreciate on-going feedback.   20 organisations were represented at the meeting with a range of involvement in Filesender – from those with an initial interest in deploying Filesender to organisations that have been using the software in production for a number of years.

The Filesender Board (Jan Meijer, Guido Aben, Nicole Harris and Rogier Spoor) gave an update on the current status of Filesender 2.0 and presented the future Filesender roadmap for the first time.  These are the main areas that have been identified as useful for the community, but delivery of features will be determined by funding that the project can attract and priorities for funding organisations.

Questions from the room revolved around Filesender 2.0 and the desire to have this available – now please!  Due to the success of moving to the Commons Conservancy, Filesender has recently been able to hire a new developer and work is underway to release 2.0 as soon as possible. You can keep an eye on our commits on github to see the work as it happens.  A lot of the features requested in the room – theming, crypto, more control of notifications, email bounce handling, multi-file transfer – are on the feature list for Filesender 2.0.

The audience was interested in the work of the Commons Conservancy, not only as a mechanism to donate to Filesender but as a future home for other software projects. The MoU signed between GÉANT, NLnet and the Commons Conservancy is designed to recognise this growing need in our community and provide support for projects that wish to make the move to a more sustainable framework.  the GÉANT Greenhouse SIG provides opportunities for projects to prepare for such a move, as well as being a forum for discussion on all issues around NREN use of open source.

Finally, Filesender can only continue to grow with your contributions.  If you use Filesender, want to use Filesender or want the project to improve so that it has the features you need please do visit the Commons Conservancy website and donate!  If you have any questions, please reach out to the Filesender team.

 

Alpha, beta, release candidate and production releases

We haven’t really made a line-in-the-sand release announcement of version 2.0-alpha. This was partly because we didn’t really have a good definition of what we mean by an alpha release and how it’s different from a beta release. This post is intended to clarify this and to ensure that our community has the right expectations of our various releases. The related pages at www.filesender.org will be updated shortly. We would appreciate community feedback on this blog post: please let us know whether our definitions match your expectations via the filesender-dev mailing list.

A release goes from “a bucket of code”, through “alpha”, “beta” and “release candidate”, to production “release”.

Characteristics of a FileSender alpha:

  • Draws a line-in-the-sand from where development will move from “adding to a bucket of code” towards “getting code and documentation to a production release state”.
  • Has adequate installation documentation but may require more installation and configuration effort from a system administrator than a production release will.
  • Has not undergone structured client-side workflow testing.
  • Must be assumed to have unknown issues.
  • The feature list is mostly stable but can change.
  • Documentation is typically incomplete.
  • Has been through some basic tests by developers: usually this means automated unit tests on software components, and verification by the developer and verification on an independent installation installed from Subversion (SVN) that at least the most basic functionality (uploading and downloading of a file) proceeds as intended with at least one browser.
  • Is released through SVN. We want the community to be able to update their alpha release based installation as soon as new code is available and without too much hassle. Inserting a packaging step before releasing alpha versions would delay and further complicate the alpha release procedure.
  • Release announcement includes the SVN branch name and revision number – it is that specific SVN checkout that is considered to be the specific alpha release.
  • There can be multiple alpha releases. They will be labelled alpha-1, alpha-2 etc..

Characteristics of a FileSender beta:

  • Has undergone some structured client-side workflow testing.
  • Should be easy to install and the tested features should simply work.
  • Feature list is being stabilised. This implies a new-feature freeze when releasing the first beta. It also implies a documented understanding of the feature list by the last beta release.
  • A summary of structured client-side workflow tests conducted per beta release typically indicates which features have been tested and with which browser(s).
  • You should not encounter unknown issues in tested features. Note that not all features may be tested for a particular beta release.
  • Is at a minimum released as a tarball.
  • There can be multiple beta releases. They will be labelled beta-1, beta-2 etc..

Release candidate:

  • At some point in the release cycle, the list of all features that we wish to ship in a functional state should be documented and collectively present in one single beta release. After that particular beta has undergone structured client-side workflow testing and been released, and has also proven itself stable in field testing, this beta release can become a release candidate.
  • This is the release where we are confident that we have identified the important known issues and that there are no show-stopping issues.
  • Small bug fixes since the last beta release can be added to the release candidate.
  • Is at a minimum released as a tarball.
  • After release will be field-tested on at least two FileSender release candidate test sites:
    • Production sites with at least X transfers by X unique users per day.
    • The sites run with well-known configurations making what are considered standard features available to their user bases.

Release:

  • Once a release candidate has been running production traffic with live users for at least two weeks on at least two release candidate test sites and shown no significant issues impairing service for the users, it can become the production (major) release.
  • There are no code, database or configuration file changes between a release candidate and a release.
  • Is at a minimum released as a tarball.
  • At some point(s) prior to a production (major) release, the code has been subjected to at least one external code security audit.

 

The following pages will be updated as part of this policy clarification:

We would appreciate community feedback on this blog post: please let us know whether our definitions match your expectations via the filesender-dev mailing list.

filesender.org (Assembla) down 24 Febraury 2015

The FileSender project uses the Assembla project hosting service to host its documentation, code and tickets.  Assembla was down for 10 hours on 24 February 2015 and as a consequence both www.filesender.org and it’s redirection target https://www.assembla.com/spaces/file_sender/ were unavailable.

Assembla has published an outage report:

“for about 10 hours starting at 03:15 UTC on 24 February.  All services are restored with no data loss. – See more at http://blog.assembla.com/assembla-was-down-here-is-the-explanation

New systems do generate new problems, but sometimes also old and well-known problems 😉