Update user manual URL in README.md § Tutorial #1735
Conversation
The previous link ( http://www.openshotusers.com/help/en/ ) leads to a vaguely-shady-looking placeholder page.
ferdnyc
changed the title
|
Hmm, seems this got left out of 2.4.2. Only affects the |
|
uh uh... and same with the master branch. This got left out of there too. One of the cons of git-flow, again? o.O |
Well, that part's correct w/in the Flow model, as "master only contains released code".
Hard to say for certain, but that seems likely. Quoting from Corey Quinn's "Terrible Ideas in Git" post today...
(That the image in question is the standard Git Flow model diagram is not lost on his audience.) |
Actually, it's probably more accurate to say that it's a pitfall of Git Flow when used in combination with Github's online-documents model. When the |
|
Hmm... perhaps this will resolve itself once a release branch has been made from develop and later merged into master... But yeah. git flow is confusing... |
|
Oh, it'll resolve itself as soon as the next release branch is forked from develop, at that point it will become part of the release source. The master branch serves no real purpose in Flow, TBH. Its entire function ("master holds all the released code") could be achieved by simply keeping release branches around post-release. Or just by referencing the tagged commit that represents each release. It's like the people who came up with Flow didn't understand that branches are not filesystems, and you don't need to have commits sitting around at the HEAD of a branch in order to access/retain them. |
|
I wonder what 'flow' is used for big projects - like GIMP and Linux kernel... |
HAHAHAHA! If I know the Gimp developers, they're probably keeping their central code repository in CVS, stored on DAT tapes in an old shoebox somewhere. The kernel, AIUI it's mostly the flow of invective from Linus' mouth when you submit bad patches that keeps people honest, more than any release process. But, no, the kernel does have a VERY structured, multi-tiered release process, as you'd expect of a project that manages literally millions of lines of code changes per year, from thousands of developers. But it's also completely specific to that effort, and not generally applicable to any other project. (If you think Git Flow is overcomplicated — and it is, it absolutely is — the kernel devel process is like one of those massive, planetwide bureaucracies sci-fi writers love to imagine humanity evolving towards. ...And kind of proves their point, come to think of it.) |
|
GIMP development has moved to gitlab, BTW. :D Hmm... I see... I sure hope git flow works well for us. :) |
|
Yeah, and I was going to say "but they haven't released anything in like a year", but I see that's not true. They finally did get 2.10 out the door. So, good for them! Still, a look at https://gitlab.gnome.org/GNOME/gimp/branches/all reveals that they don't impose a particularly structured process for managing releases in the tree. Developers create whatever branches they want, do whatever they want in them, and it looks like when they're getting close to a release they fork a branch from master and ready it there. Pretty standard, especially within Gnome projects. |
|
They got 2.10.4 out just a few days ago, too, BTW. I really hope 3.0 series will be out soon. 3.2 will bring adjustment layers on the scene too. Also, they've got this gegl thing (I don't really understand much about these at all) and evidently, it can be used for video processing too. At least a Linear video editor based on it has been made. https://github.com/hodefoting/gedl |
That doesn't really count, 2.10.2 and 2.10.4 are scrambly bugfix releases to paper over issues with 2.10.0, the same way we'll hopefully be scrambling to get an OpenShot 2.4.2.1 (at least) out. 2.10.0, which came out two months ago, was the first major release since 2.8 which was six years ago. And I wouldn't hold your breath for 3.0, since based on the pattern that'll be out in roughly the year 2024. That puts 3.2 at around 2030. |
|
Hmm... How about the end of 2018? (I think I saw it somewhere that because 3.0 is just going to be a port to GTK3 and nothing else - but that hasn't really been the case, they're also re-factoring the code - it's going to be out soon after the release of 2.10) I wonder why Red Hat and Gnome Foundation don't fund GIMP development. It is a gem. |
|
*chuckle* Can't wait to find out whether the GTK3 port gets done before or after the release of GTK4. |
|
It won't. GTK 4 is almost ready (according to a tweet that I saw a few days earlier). Oh GIMP, why you disappointing me? |
The previous link ( http://www.openshotusers.com/help/en/ ) leads to a vaguely-shady-looking placeholder page.