GNOME.org
 

[pitivi] docs: Replaced phabricator links with gitlab

commit bec7eafc1bb69839f5934a459e7903bdce9c83b0
Author: Alexandru Băluț <alexandru balut gmail com>
Date:   Sat Apr 14 07:34:04 2018 +0200

    docs: Replaced phabricator links with gitlab

 .arcconfig                    |   7 -
 docs/Bug_reporting.md         |   9 +-
 docs/Development_workflow.md  |  27 ++--
 docs/Git.md                   |  25 ++--
 docs/Google_Summer_of_Code.md |  10 +-
 docs/QA_Scenarios.md          |   4 +-
 docs/Roadmap.md               | 316 ++++--------------------------------------
 docs/release.md               |   8 +-
 8 files changed, 69 insertions(+), 337 deletions(-)
---
diff --git a/docs/Bug_reporting.md b/docs/Bug_reporting.md
index 48b6cfd3..16ea2af7 100644
--- a/docs/Bug_reporting.md
+++ b/docs/Bug_reporting.md
@@ -3,14 +3,13 @@
 Welcome, testers!
 
 To report a bug/problem in the software, or request a new
-feature/enhancement, [create a
-task](https://gitlab.gnome.org/GNOME/pitivi/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=)
-and set Projects: Pitivi.
+feature/enhancement, [create an
+issue](https://gitlab.gnome.org/GNOME/pitivi/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=).
 
 Bug reporting and feature requests are managed with GNOME's
 [GitLab](https://gitlab.gnome.org/). You need to create
-an account to file tasks and comment on them. Take a look at the
-[existing list of bugs/feature
+an account to file issues and comment on them. Take a look at the
+[existing list of bugs and feature
 requests](https://gitlab.gnome.org/GNOME/pitivi/issues) to see if
 your problem has already been reported.
 
diff --git a/docs/Development_workflow.md b/docs/Development_workflow.md
index a3d7937e..5fe1011d 100644
--- a/docs/Development_workflow.md
+++ b/docs/Development_workflow.md
@@ -4,22 +4,27 @@ short-description: How we do it
 
 # Development Workflow
 
-We use [Gitlab](https://gitlab.gnome.org/GNOME/pitivi/issues) to track all
-bugs and feature requests. Feel free to open a task if you have found a
-bug or wish to see a feature implemented. If it already exists,
-subscribe to it to keep yourself updated with its progress. You can also
-subscribe to the entire project.
+We use [GitLab](https://gitlab.gnome.org/GNOME/pitivi/issues) to track
+all bugs and feature requests. Most of the time, you assign an issue
+to yourself, work on it until it's fixed, and then you close it.
 
-## Picking a task to work on
+Interested users can enable notifications for an existing issue to
+get an email when it's updated. It's also possible to change your
+"Notification settings" for
+[pitivi](https://gitlab.gnome.org/GNOME/pitivi) from the default
+"Global" to "Watch", to receive notifications for any activity in the
+entire project.
 
-To get involved, you can start with tasks tagged [Pitivi tasks for
-newcomers](https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=4.+Newcomers).
+## Picking an issue to work on
+
+To get involved, start with issues tagged
+[4. Newcomers](https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=4.+Newcomers).
 It's best to get in touch with us on our IRC channel `#pitivi` on
 Freenode, to see if it's still meaningful.
 
-Once you decide, assign the task to yourself in GitLab.
+Once you decide, assign the issue to yourself in GitLab.
 
-## Fixing the task
+## Fixing the issue
 
 Next is the fun part where you implement your cool feature, or fix an
 annoying bug:
@@ -63,4 +68,4 @@ want to create.
    pushing or in the GitLab UI clicking "Create merge request" in your branch.
 
 [Gitlab workflow for contribution]: https://gitlab.gnome.org/GNOME/pitivi/
-[gitlab]: https://gitlab.gnome.org/GNOME/pitivi/
\ No newline at end of file
+[gitlab]: https://gitlab.gnome.org/GNOME/pitivi/
diff --git a/docs/Git.md b/docs/Git.md
index c5d8d592..ecb57b19 100644
--- a/docs/Git.md
+++ b/docs/Git.md
@@ -20,30 +20,27 @@ ready](http://gitready.com).
 ## Sending changes around
 
 As can be seen in the [development workflow](Development_workflow.md),
-we normally don't take care of pushing branches around, as this is done
-automatically by git-phab. Once somebody attaches a branch to a task
-with git-phab, all of us can try it with:
-
-```
-git-phab fetch T1234 -c
-```
+best is to create an account on the GNOME GitLab instance and fork
+[Pitivi](https://gitlab.gnome.org/GNOME/pitivi) there to create
+your own remote `pitivi` repository. When you push branches to this
+remote repository, you have the option to create a merge request.
+A GitLab merge request is the same things as a GitHub pull request.
+This way, the maintainers and other interested parties are notified
+and can review the changes.
 
 
 ## When to use git pull
 
 With rare exceptions, in Pitivi we rebase contributed commits before
 pushing them to origin/master, to avoid merge commits. This worked fine
-and it enforces some discipline, so there is no plan to change it. It's
-similar with Phabricator's philosophy (`arc land` squashes all the
-commits in the current branch into a single one before pushing to
-origin/master) — just that we like to keep control.
+and it enforces some discipline, so there is no plan to change it.
 
-When working on a task, assuming you're following the [development
+When working on a issue, assuming you're following the [development
 workflow](Development_workflow.md), you should have a specific branch.
 To get the latest changes in your branch, normally in Pitivi you should
 do something like `git fetch` and `git rebase origin/master`.
 
-It should be safe to use `git pull` on the master branch if you don't
+It should be safe to use `git pull` on the master branch, if you don't
 work on it. Just make sure it's exactly what origin/master is and no
 merge commit is created.
 
@@ -56,7 +53,7 @@ using a graphical tool such as `gitk` or
 really nice interface).
 
 [Meld](http://meldmerge.org) can be very useful for reviewing a large
-change to be committed.
+change to be committed. Simply run `meld .` in your local repository.
 
 Set up your prompt to show the current branch info, and make sure
 tab-completion works.
diff --git a/docs/Google_Summer_of_Code.md b/docs/Google_Summer_of_Code.md
index 0204339f..d7508a22 100644
--- a/docs/Google_Summer_of_Code.md
+++ b/docs/Google_Summer_of_Code.md
@@ -107,7 +107,7 @@ Therefore, you should proceed like this:
     doesn't, etc. See how you like it.
 3.  To get a better idea of how comfortable you are with the code and
     community, make some small contributions to the code. Pick some
-    small [bugs] to fix or pick a “small” task in the [Pitivi tasks for
+    small [bugs] to fix or pick a “small” task in the [fun tasks for
     newcomers] list and have a go at it. Keep us in the loop. The
     earlier you start contributing, the more likely you know what you're
     getting into. Don't start contributing in March/April: we highly
@@ -125,8 +125,8 @@ Therefore, you should proceed like this:
   [IRC channel]: http://www.pitivi.org/?go=contact
   [development environment]: https://github.com/pitivi/pitivi/blob/master/docs/HACKING.md
   [Test suite]: Testing.md
-  [bugs]: https://phabricator.freedesktop.org/project/view/15/
-  [Pitivi tasks for newcomers]: https://phabricator.freedesktop.org/tag/pitivi_tasks_for_newcomers/
+  [issue]: https://gitlab.gnome.org/GNOME/pitivi/issues
+  [fun tasks for newcomers]: https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=4.+Newcomers
   [application]: https://wiki.gnome.org/Outreach/SummerOfCode/Students#Fill_out_the_Application
   [website]: https://developers.google.com/open-source/gsoc/
 
@@ -150,7 +150,7 @@ multiple codebases:
 We'd love to see GSoC proposals originating from an itch you need to
 scratch. You are welcome to ask around and **bring your own ideas**. If
 you're not sure where you can be most useful, have a look at the “large”
-tasks in the [Pitivi tasks for newcomers] list. They are fun cool
+tasks in the [fun tasks for newcomers] list. They are fun cool
 features very suitable for a GSoC project. See the [roadmap] for our
 overall vision for the project. Deadlines for applying are approaching
 fast, hurry up!
@@ -160,6 +160,6 @@ See [Past GSoCs] for details on what the previous GSoC students did.
   [architecture]: Architecture.md
   [GES]: GES.md
   [Pitivi]: http://www.pitivi.org/manual/mainwindow.html
-  [Pitivi tasks for newcomers]: https://phabricator.freedesktop.org/tag/pitivi_tasks_for_newcomers/
+  [fun tasks for newcomers]: https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=4.+Newcomers
   [roadmap]: Roadmap.md
   [Past GSoCs]: Past_GSoCs.md
diff --git a/docs/QA_Scenarios.md b/docs/QA_Scenarios.md
index 34e7e026..547298d0 100644
--- a/docs/QA_Scenarios.md
+++ b/docs/QA_Scenarios.md
@@ -1,8 +1,8 @@
 These QA Scenarios are here to check the expected behaviours of Pitivi
 under many situations.
 
-If you see a problem in one of them, [Create a
-task](Bug_reporting.md) on Phabricator, indicating:
+If you see a problem in one of them, [create an issue](Bug_reporting.md)
+on GitLab, indicating:
 
 -   which QA Scenario doesn't go through,
 -   (optionally) the media files you used,
diff --git a/docs/Roadmap.md b/docs/Roadmap.md
index 93ddb9b9..0d1ad245 100644
--- a/docs/Roadmap.md
+++ b/docs/Roadmap.md
@@ -3,13 +3,13 @@
 This is intended to be a **general overview** of the very
 important or big features/improvements we are working on, or planning.
 For a list of smaller features see [fun tasks for
-newcomers](https://phabricator.freedesktop.org/project/view/111/).
+newcomers](https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=4.+Newcomers).
 
 What keeps us busy in general?
 
 -   **Fixing bugs**. Improving reliability and ease of use is never
     “done”. We have
-    [tons](https://phabricator.freedesktop.org/tag/pitivi/) of work.
+    [tons](https://gitlab.gnome.org/GNOME/pitivi/issues) of work.
     [Help](http://www.Pitivi.org/?go=contributing) is very welcome!
 -   **Improving GStreamer**. This benefits not only Pitivi, but other
     multimedia applications as well.
@@ -22,10 +22,7 @@ Any time estimates here are mostly wild guesses. Do not treat them as
 hard deadlines. This aims mostly at giving an idea of how milestones
 follow each other.
 
--   2016 Q2: release [0.96](releases/0.96.md) with a focus on
-    stabilization and accuracy through proxy files
--   2016 Q4 or 2017 Q2: release [1.0](releases/1.0.md) with ponies and
-    rainbows
+-   2018 Q4: release [1.0](releases/1.0.md) with ponies and rainbows
 
 See [Current events](Current_events.md) for past items.
 
@@ -33,37 +30,45 @@ See [Current events](Current_events.md) for past items.
 
 ## Plugin system
 
--   Status: planning.
+-   Status: [done](https://gitlab.gnome.org/GNOME/pitivi/issues/1480),
+    but we still need a [developer
+    console](https://gitlab.gnome.org/GNOME/pitivi/issues/2055), and
+    [documentation with
+    examples](https://gitlab.gnome.org/GNOME/pitivi/issues/2089).
 -   **This is very important**. A plugin would have access to the entire
     app. Being in Python, it will be extremely easy to quickly write
     useful plugins without having to compile anything. Pitivi plugins
     will allow manipulating the timeline clips and clip effects
     automatically, thus allowing great flexibility for custom solutions.
-    See the [tasks blocked by
-    T3193](https://phabricator.freedesktop.org/T3193) for a few examples
-    where this will be useful.
+    See for example [audio
+    normalization](https://gitlab.gnome.org/GNOME/pitivi/issues/638)
+    or the [autoaligner
+    ressurection](https://gitlab.gnome.org/GNOME/pitivi/issues/1345).
 
-## Motion ramping/time stretching
+## Motion ramping, time stretching
 
 -   Status: started
--   See [T2344](https://phabricator.freedesktop.org/T2344)
+-   See [issue 632](https://gitlab.gnome.org/GNOME/pitivi/issues/632)
 
-## Effects
+## Effects UI
 
--   We need to create custom (“hand-made”) interfaces for some effects
-    so that they can be easier to use. See
-    [T3263](https://phabricator.freedesktop.org/T3263)
+-   Status: some effects like
+    [alphaspot](https://gitlab.gnome.org/GNOME/pitivi/issues/2098) and
+    [color corrector](https://gitlab.gnome.org/GNOME/pitivi/issues/660)
+    already have a custom UI. The overall experience can be smoother.
+-   Still to do: [green screen
+    compositing](https://gitlab.gnome.org/GNOME/pitivi/issues/966),
+    [audio equalizer](https://gitlab.gnome.org/GNOME/pitivi/issues/1551)
 
 ## Advanced layer management
 
--   See [T2642](https://phabricator.freedesktop.org/T2642#85395)
+-   See [issue 930](https://gitlab.gnome.org/GNOME/pitivi/issues/930#note_68393)
 
 ## A better title editor
 
 -   The current title editor UI is very simple. Please join us to make
-    it work up to your expectations! See the existing
-    \[<https://phabricator.freedesktop.org/maniphest/?statuses=open>()&projects=PHID-PROJ-ext-TITLEEDITOR\#R
-    title editor tasks\].
+    it work up to your expectations! See the existing [title editor
+    issues](https://gitlab.gnome.org/GNOME/pitivi/issues?label_name%5B%5D=titles+editor).
 
 ## MAM/DAM
 
@@ -86,275 +91,8 @@ See [Current events](Current_events.md) for past items.
 
 ## Proxy editing
 
+-   Status: [done](https://gitlab.gnome.org/GNOME/pitivi/issues/743) but
+    the proxy experience can be better
 -   See [proxy editing
     requirements](design/Proxy_editing_requirements.md) for the “spec”
     of how this feature should behave
--   See [T2455](https://phabricator.freedesktop.org/T2455)
-# Proxy editing requirements
-
-See [T2455](https://phabricator.freedesktop.org/T2455) to learn about
-proxy editing and why we want this in [GES](GES.md) and Pitivi.
-This page is meant to brainstorm:
-
--   User interface/user experience (UX) possibilities and requirements
--   GES API requirements deriving from that. This also touches on media
-    assets management in general.
-
-Prior art if you don't know what proxy editing “feels” like:
-
--   [In Edius](http://www.youtube.com/watch?v=SyUvp0YqLpc). This is an
-    interesting example of a badly designed UI: pretty much all the
-    options/preferences presented there are useless, the application
-    should be smart enough to make those choices!
--   [In FCP X](http://www.youtube.com/watch?v=MnZx3JxoR-A) (alternative
-    [longer version](http://www.youtube.com/watch?v=aL7gE-my4_c))
--   [In Sony Vegas](http://www.youtube.com/watch?v=4PE6tDjgDEY)
--   Others we should be looking at in particular? Some particularly
-    great (short and to the point) video tutorials of other apps we
-    ought to see? Let us know.
-
-# User experience
-
-As [T2455](https://phabricator.freedesktop.org/T2455) indicates, we can
-envision two types of user experience: a semi-automatic and a
-fully-automated one. Since Pitivi is not the only application (now and
-in the future) using GES, we need to design the GES API to be flexible
-enough to accommodate the design needs of both kinds of applications.
-
-In both cases, the experience must be:
-
--   Intuitive: it should be a very easily discoverable feature
--   With good visual indications of the process and progress. We should
-    probably have some sort of “yellow/green light” (red for errors)
-    icons somewhere near each clip in the media library to indicate the
-    status of individual proxies. Remains to be seen how we can do this
-    with iconview mode and listview mode without going insane.
--   Fluid, with no negative performance impacts from the act of
-    generating the clip “proxies”
-
-## Icons representation
-
-Since the Media Library's iconview is meant to be compact and
-minimalistic (and has a fair amount of technical limitations), we could
-use the following icon metaphor system to indicate the states of proxies
-for assets:
-
-  Status icon   Icon's opacity   Thumbnail's opacity   Meaning
-  ------------- ---------------- --------------------- 
----------------------------------------------------------
-  None          N/A              100%                  Proxies are disabled for this asset
-  Gears/sync?   100%             50%                   A proxy is currently being generated for this asset
-  Checkmark     70%?             100%                  Proxies are present and ready for this asset
-  ⚠ (warning)   100%             100%                  The proxy could not be generated for this asset
-  ⚠ or X        100%             50%                   A proxy file is present, but the original file is 
absent
-
-## Manual/semi-automated UX
-
-In this mode, users would manually select which assets/clips use
-proxies, and when the proxies are generated. There would be no
-“automated” background processing. This is probably not what we want in
-Pitivi in terms of the default user experience, however the GES API
-should support that scenario. We could still provide this feature in
-pitivi by:
-
-1.  Having an option in the preferences, under the “Performance”
-    section: “Automatically create proxies for clips in the media
-    library”
-2.  If that option is disabled, show a toolbar button in the media
-    library that, when clicked, generates the proxies for selected
-    clips.
-
-However this also means temporarily providing a “Cancel” button while
-those clips' proxies are being generated. Additionally to the “status
-lights” icons mentioned earlier, we could perhaps show a progressbar
-(with a “Stop” button on its right) below the media library (similar to
-when we're importing clips).
-
-Jakub commented:
-
-> “Semi-automatic - I don't grok this experience. Why would I want to
-> explicitly hold the burden of being a transcoding manager? I like the
-> validity checking and ability to explicitly re-render a proxy though.
-> Ran into issues in both kdenlive and FCPX where I spent ages looking
-> for a faulty proxy.”
-
-To balance things, Bassam commented:
-
-> "manual vs. automatic: however the ui is chosen, this should be a per
-> project setting, not a choice of a different application. both
-> workflows are valid, and the same person might opt for one or another
-> depending on the specifics of the project. \[...\]
-
-## Fully-automated UX
-
-Otherwise, the default behavior would be to transparently (and
-intelligently) create proxies for everything, in the background. When a
-proxy file does not exist for an asset (clip), create it and use it as
-soon as it has been created.
-
-Performance requirements in the automated scenario are even more
-important than in the semi-automated scenario; while users can expect
-some delay (as long as there is a visual progress indication) when they
-manually trigger an action, they must absolutely *not* feel
-delays/sluggishness when such actions are triggered automatically. The
-generation of proxy clips in the background should not negatively impact
-system performance.
-
-Jakub has a different opinion than Jeff's or Bassam's, suggesting (?)
-that we make proxy generation a modal (blocking, in terms of UI)
-operation:
-
-> "You mention the problem of indicating the transcoding process as if
-> you could continue working with original assets and have that not stop
-> you from editing work with original media. In case of offline editing
-> (either having assets on external drive, or networked/cloud storage),
-> the indication can be summed up to “tell me when my assets are safe to
-> disconnect and I'm able to proceed editing offline”. For low
-> performing systems, the background transcoding is just an illusion,
-> you cannot really edit until your assets are transcoded. So I think
-> both cases are best addressed by providing an aggregate progressbar
-> telling me when all assets referenced from the project are transcoded,
-> rather than colorcoding individual clips, or worrying about preview
-> overlays. \[...\] For offline editing I would agree not choking the
-> system competely with transcoding might be a good thing, but for the
-> low performing system case you want the transcoding process to take
-> the foreground so that the assets are ready sooner. You really can't
-> do any 4k editing on a laptop and expect to also transcode proxies in
-> the background."
-
-# GES API requirements
-
-## Control
-
--   Proxies generation/processing needs to be pause-able
-    -   When pitivi starts playback (or render) and needs the system's
-        resources
-    -   When the user pauses proxy generation (in the case of the
-        semi-automated UX)
--   Proxies generation needs to be cancel-able
-    -   When the user asks to stop generating proxies for selected clips
-        (in the case of the semi-automated UX)
--   The ability to “force” regenerating the proxies for a given asset
-    (for whatever reason)
--   Delete a proxy (or all proxies) for a given asset
--   Relocate/move proxies for a given asset or for all assets
--   Ability to manually replace an offline asset.
-
-## Data integrity checking
-
--   Need a way to detect incomplete or invalid proxies, to handle
-    various scenarios:
-    -   The user has quit the application before it was done processing
-    -   The application crashed
-    -   The source file has changed (use a md5 on the first few bytes of
-        the file like in pitivi/previewers.py and store that hash in the
-        GES Asset?)
-
-## Signalling/notifying
-
--   For each asset, report the proxies' encoding progress, so the
-    application UI can show progressbars or some other form of visual
-    indications
--   Provide a way to signal to the application that an asset has its
-    original offline, or its proxy offline, or whatever situation we can
-    imagine, so the UI can let the user know about it.
--   Tolerate and signal errors/failures.
-
-## Fault tolerance and sandboxing
-
--   Tolerate and signal errors/failures.
--   Processing should probably happen in a separate/sandboxed process,
-    to ensure that GES/applications can't crash because of something
-    going wrong during the processing of a proxy
--   GES needs to handle the notion that an asset and/or any of its
-    proxies can go offline/online. For example, if the original clip is
-    not available but the proxy version is present, consider the
-    original “offline” and use the proxy version.
-    -   The way we handle “missing” media needs to change: currently
-        Pitivi just refuses to handle “partial” projects, but in theory
-        it should “deal with it”. Even if all the assets of a clip
-        (including proxies) are offline.
-    -   If an asset or its proxies were moved/renamed externally, allow
-        specifying the new location (already mostly implemented in GES
-        assets?), but don't force it. Proxies/assets for which the user
-        has not provided replacements are to be marked as temporarily
-        “offline” (we should also save info about the last time it was
-        seen, its metadata/attributes, etc.).
-
-## Additional API flexibility
-
--   Multiple ways to handle offline assets for rendering and export:
-    -   “Draft render” mode (low quality render using only the proxies
-        instead of the original clips), as some applications might like
-        to offer that feature.
-    -   Rendering to a multimedia output file requires original assets
-        to be “online”. Otherwise, if only proxies are available, we
-        can:
-        -   Warn the user about reduced quality. If some assets have no
-            originals and no proxies, show a serious warning.
-        -   Export only an EDL (edit decision list), but that's [another
-            story](https://bugzilla.gnome.org/show_bug.cgi?id=674605)
--   Provide a way to specify which containers, codecs and settings (ex:
-    video resolution, bitrate/quality) to use for proxies. This will
-    probably use a technology similar to what we see in Pitivi's render
-    dialogs.
--   Allow multiple proxies per asset (for multiple resolutions, for
-    example). The application should be able to request a proxy to match
-    a particular context (ex: a maximum resolution or something); for
-    example, multicam editing could use very small versions if there is
-    a big number (ex: 16) of camera angles to be displayed
-    simultaneously. Or the media library could automatically show a
-    playing thumbnail-sized video preview when putting the mouse over a
-    clip.
--   Ability to save, in a project formatter's data, the following
-    per-project overrides of the global app settings:
-    -   A custom folder path for the proxies for that project (see also
-        the “where to store the proxies?” item in the “outstanding
-        questions” section on this page).
-    -   Whether this project prefers fully-automated (or manual)
-        handling of proxies (Bassam said: “However the ui is chosen,
-        this should be a per project setting, not a choice of a
-        different application. Both workflows are valid, and the same
-        person might opt for one or another depending on the specifics
-        of the project.”)
-
-# Outstanding questions
-
--   Where to store the proxies? (beyond the obvious question of disk
-    space and tidiness, there's the question of people working across
-    networks that raises interesting questions)
-    -   In pitivi we could default to the XDG user cache dir (which in
-        this case would turn out to be \~/.cache/pitivi/proxies/)
-    -   ...but Bassam insists that this can be overridden on a
-        per-project basis. So in the project settings UI, we could have
-        a checkbox to “Use a custom directory to store proxies” that
-        enables a gtk folder chooser button right besides it. Unchecking
-        the checkbox would clear the project's custom directory.
--   Filenames of the actual proxy files depending on their location
-    (global cache folder vs project folder?). For example, if a clip is
-    called “foo.MOV”, should the proxies be called foo-360p.gesproxy, or
-    foo--proxy-360p.webm, or C462NTH353.webm in the hidden cache folder,
-    or...?
--   Codecs? So far we're hesitating between MJPEG and VP8. MJPEG is
-    handsdown the fastest codec to seek and to encode, since it is so
-    simple and every frame is a keyframe - however, the filesize is
-    rather big. VP8 is more configurable and can be made to approximate
-    MJPEG's seeking performance, but it is significantly more expensive
-    to encode.
--   Resolutions, and how to handle aspect ratios. That is, how do you
-    determine the appropriate resolution depending on the aspect ratio
-    and resolution of the source material?
-    -   Going with a hardcoded percentage (ex: 50% of the original's
-        resolution) can be bound to fail in scenarios where the original
-        has a huge native resolution (such as 4K).
-    -   Alternatively, one can imagine a hardcoded (or configurable)
-        “max resolution”, where clips bigger than that resolution will
-        have proxies created to “fit the box” (in terms of width and
-        height, whichever comes first). Hardcoding the box resolution
-        might be problematic as computers become more powerful and
-        screen resolutions increase.
-    -   Ideally, we need a clever algorithm to figure out all of this
-        automatically. Any rough ideas of the logic here? Let us know.
-        Solutions where the software can be smart enough to figure the
-        optimal resolution to use, instead of having the user deal with
-        it, are preferred.
--   Handling “tarball export” in Pitivi
diff --git a/docs/release.md b/docs/release.md
index fa99f7d1..2b354897 100644
--- a/docs/release.md
+++ b/docs/release.md
@@ -12,10 +12,10 @@ number (1, 2, 3...).
 
 Most of the steps below should be done in the [development environment](HACKING.md): `$ source 
bin/pitivi-env` -> `(ptv-flatpak) $`
 
-1. Check [Phabricator](https://phabricator.freedesktop.org/tag/pitivi/)
-    * Make sure there is no open 'blocker' task against the current milestone.
-    * Move the other open tasks somewhere else, for example to the next milestone.
-    * Archive the current milestone. Open the milestone's workboard, click Manage, then Archive Project.
+1. Check [GitLab](https://gitlab.gnome.org/GNOME/pitivi/milestones)
+    * Make sure there are no significant issues open against the current milestone.
+    * Move the remaining open issues somewhere else, for example to the next milestone.
+    * Close the current milestone.
 
 2. Make sure we depend on the latest GStreamer. This should be done as soon as GStreamer makes a release.
     * Find the latest tag in https://cgit.freedesktop.org/gstreamer/gstreamer/
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]