After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 757735 - Programming guidelines: misc improvements
Programming guidelines: misc improvements
Status: RESOLVED FIXED
Product: gnome-devel-docs
Classification: Applications
Component: programming-guidelines
3.18.x
Other All
: Normal enhancement
: ---
Assigned To: GNOME Devel docs: Programming Guidelines maintainer(s)
gnome-devel-docs maintainers
Depends on:
Blocks:
 
 
Reported: 2015-11-07 14:46 UTC by Sébastien Wilmet
Modified: 2015-11-07 17:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
programming-guidelines: time complexity fixes (1.16 KB, patch)
2015-11-07 14:47 UTC, Sébastien Wilmet
committed Details | Review
programming-guidelines: merging release commits (1.71 KB, patch)
2015-11-07 14:47 UTC, Sébastien Wilmet
committed Details | Review
programming-guidelines: don't use the term "pre-release increment" (2.24 KB, patch)
2015-11-07 14:47 UTC, Sébastien Wilmet
committed Details | Review
programming-guidelines: fixes in the API stability page (1.33 KB, patch)
2015-11-07 15:20 UTC, Sébastien Wilmet
committed Details | Review

Description Sébastien Wilmet 2015-11-07 14:46:26 UTC
See the attached patches.
Comment 1 Sébastien Wilmet 2015-11-07 14:47:44 UTC
Created attachment 315045 [details] [review]
programming-guidelines: time complexity fixes

- O(N^2) is quadratic, not exponential. Exponential is O(2^N).
- Constant factors should be removed, since it's an asymptotic notation.
Comment 2 Sébastien Wilmet 2015-11-07 14:47:50 UTC
Created attachment 315046 [details] [review]
programming-guidelines: merging release commits

Absolutely requiring a linear Git history can be painful when doing
releases. Re-running make distcheck is not the funniest thing to do and
can take a long time (compiling the API documentation, running the
tests, etc). So I think a small exception to the rule is acceptable.

There was a discussion about that on the desktop-devel-list:
https://mail.gnome.org/archives/desktop-devel-list/2014-July/msg00027.html
the conclusion was that merging the release commit was the simplest
solution.
Comment 3 Sébastien Wilmet 2015-11-07 14:47:56 UTC
Created attachment 315047 [details] [review]
programming-guidelines: don't use the term "pre-release increment"

When reading the text, I first thought that it meant "pre-commit" and
"post-commit". But the pre-commit is useless, it can be done at the same
time as the release commit.

Saying "at the time of release" is clearer in my opinion.
Comment 4 Philip Withnall 2015-11-07 15:06:26 UTC
Review of attachment 315045 [details] [review]:

++
Comment 5 Philip Withnall 2015-11-07 15:09:23 UTC
Review of attachment 315046 [details] [review]:

++
Comment 6 Philip Withnall 2015-11-07 15:10:26 UTC
Review of attachment 315047 [details] [review]:

++
Comment 7 Sébastien Wilmet 2015-11-07 15:20:30 UTC
Created attachment 315053 [details] [review]
programming-guidelines: fixes in the API stability page

When the API breaks, the major number is incremented, not the minor
version.
Comment 8 Sébastien Wilmet 2015-11-07 15:29:02 UTC
Attachment 315045 [details] pushed as f20cff3 - programming-guidelines: time complexity fixes
Attachment 315046 [details] pushed as 0485c4c - programming-guidelines: merging release commits
Attachment 315047 [details] pushed as ee75b63 - programming-guidelines: don't use the term "pre-release increment"
Comment 9 Philip Withnall 2015-11-07 16:05:25 UTC
Review of attachment 315053 [details] [review]:

Whoops.
Comment 10 Sébastien Wilmet 2015-11-07 17:03:48 UTC
Attachment 315053 [details] pushed as 36c4f32 - programming-guidelines: fixes in the API stability page