[Evolution] gtkhtml3.14_3.18.0-1_i386.changes REJECTED

[Loïc Minier]

On Tue, Mar 11, 2008, Heikki Henriksen wrote:
> Heh... I was sure gtkhtml3.14 was already uploaded with
> XS-Dm-Upload-Allowed: yes, but now I see it wasn't.
> 
> Loïc or Øystein. Could any of you do the honors?

 Uploaded, but there is something weird with history:
 1) unstable development of gtkhtml3.14 happens up to 3.16.x in
    unstable/
 2) package is svn cped from unstable/ to experimental/, development
    continues up to 3.17.x in experimental
 3) development in unstable jumps to 3.18.x

 This is wrong for both SVN and package history.

 For package history, you never merged the experimental uploads in the
 unstable part of our archive, so would you have closed any bug in
 3.17.x, the BTS would still consider them open since you closed them in
 versions which aren't in your unstable's debian/changelog.

 For SVN history, there are two ways to handle history:
 a) have two branches, unstable and experimental, and merge from one to
    the other; this is what would make the most sense, but it's
    incredibly painful and stupid with "svn merge ...":
    - svn merge is painful to use:
      * it doesn't know at which revisions to start/stop merging or from
        where, you have to tell it about the full URL, and the revisions
        you want to pull; on subsequent merges, you have to lookup the
        SVN rev where to start...
      * until recently (not sure now), merge wasn't doing 3-way diffs
        (diff3)...
    - it compresses history in a single commit; if you had 10 commits in
      experimental/ and merge it in unstable/, it's 1 commit in your svn
      log and no easy way to read the individual commit messages, commit
      diffs, or even know where these were done...
    with any distributed VCS, it would be a fine idea to do merges, with
    SVN it's not   :-/
 b) have one or two branches, and move the trunk around under the name
    unstable or experimental; this is easily done in SVN but moves the
    trunk continuously; it breaks expectations of svn import tools or
    simply the Vcs-Svn concept; this is achieved by:
    1) having unstable/ alone and developping there
    2) svn cping unstable/ to experimental/ when development (trunk)
       moves to experimental/ -- transforming unstable/ into a
       maintenance branch
    3) svn rming unstable/ and svn mving experimental/ to unstable/ when
       development can be published to unstable and development moves to
       unstable

 Until now, pkg-evolution followed b); in general I would recommend a),
 except with SVN where I recommend b).

 You followed neither of these for gtkhtml3.14 3.18!   :-)

 Could you please either:
 i) (preferred) fix history as if b) had been used:
   - svn merge the 3.18 changes into the experimental branch,
   - svn rm unstable/
   - svn mv experimental/ unstable/
ii) (quick fix) changes only:
   - copy the changelog entry and changes missing in unstable/ from
     experimental/ into unstable/
   - svn rm experimental/
iii)(not so quick fix with svn history) changes and weird history:
   - svn merge the experimental commits into unstable/
   - svn rm experimental/
iv) (least preferred) do a proper merge as if a) had been used:
   - svn merge the experimental commits into unstable/


 I'd rather have i).  :-)


 You need to mention the changelog merge in a new changelog entry.


 Could you also do the same to evolution-data-server which for some
 reason was committed to unstable/ with an experimental target dist?


 Also, FYI, gtkhtml3.14 failed to build because of missing libsoup2.4.
 Dunno why libsoup2.4 is missing on so many arches.


    Cheers,
-- 
Loïc Minier