Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • The Preferences  "Purpose" flag currently in use will be extended to support "Testing-Only" (the current value), and/or "Production". Repositories wishing to do both through one profile would add both values (i.e. as a JSON Array)
  • The Staging Area allows the Purpose flag to be set when matchmaking, so for 2.0 there is a mechanism for the user to see the correct list of repos given the purpose. However, since repos may not support the other options, it will now be a potential problem if users change the flag after making a selection, so, post 2.0, we could/should explore not allowing change to Purpose after selecting a repository and/or auto-updating the matchmaking results whenever the flag is changed. In the meantime, the (The service layer can check to make sure the purpose is OK w.r.t. the repo selected, but this should redundant if the staging area is making them match to start and the repositories check as they process too.).  (Since we are treating purpose as a go/no-go decision unlike other rules, which are only advisory, the proposal is to not list the repositories that can't support the request. Alternately we could cause them to be grayed-out/ use some other visual cue to indicate that the request will definitely fail.)
  • Matchmaker will look at the Purpose on the request and in the profiles and determine the match. This will be implemented as a rule. Initially, the matchmaker engine will remove entries that don't meet this requirement. Going forward, we could extend the rule definition to allow rules to be mandatory, so that the Staging Area could show repositories that cannot process the request while still stopping people from sending such requests. 
  • When a user submits a pub request, it is processed as is currently done by services and repositories with the following changes that depend on the Purpose flag setting:

...