[Pkg-mc-devel] Midnight Comander 4.8.1 [RFS]

[Andreas Tille]

On Sun, Feb 26, 2012 at 12:34:06PM +1100, Dmitry Smirnov wrote:
> I have some plans for next release.
> On BTS I've seen some yummy patches to incorporate and to forward...
> 
> Forwarding patches appears to be a next priority because we already 
> diverging from upstream...

ACK.  We should make the diff to upstream as small as possible.
 
> > IMHO the bugs.txt file makes sense when working offline.  I think
> > maintaining this file is not mandatory for an upload because while its
> > helpful for other developers as well it is not visible to users who just
> > want to recive the new package (urgently).
> 
> Personally I'd prefer BTS tags/usertags. 

Fine for me.
 
> bugs.txt was imported from SVN, so I'll keep it until I'll be sure there is 
> nothing valuable left in it.

>From my perspective the file can go.  I had a quick lock and I sometimes
create similar files before I go offline for some time and want to work
on bugs anyway.  I do not see any reason to commit such files to Vcs nor
maintain it in parallel to BTS because it becomes outdated quite quickly
and drains time to keep it up to date.

BTW, it also breaks git-buildpackage:


dpkg-source: warning: ignoring deletion of file m4.include/vfs/socket.m4
dpkg-source: warning: ignoring deletion of file m4.include/vfs/mc-vfs-tarfs.m4
dpkg-source: warning: ignoring deletion of file m4.include/vfs/mc-vfs-extfs.m4
dpkg-source: info: local changes detected, the modified files are:
 mc-4.8.1/bugs.txt
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/mc_4.8.1-1.diff.2k_uM3
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -i.git -I.git -b mc-4.8.1 gave error exit status 2


If you ask me this file should go.

 
> > The only thing which might be interesting to do before an upload whould
> > IMHO be if Maarten would check the according Launchpad bugs and add
> > these to the changelog.  However, this should also be no real reason for
> > a delay because I guess these could also be closed manually.
> 
> Changelog is already big enough and we can always close bugs in BTS.
> If we ready for upload let's upload and continue working. 
> This upload is not the last chance... :)

Fully ACK.

> It's great you've noticed this. I just pushed an update introducing symlink 
> for mc-wrapper.sh

OK.

> I think generally users might expect such changes when upgrading to new major 
> release but indeed symlink approach will be more comfortable for users than 
> NEWS.debian warning.

The link is fine for me - I just wanted to mention other possible options.

> Please excuse me for lack of experience but does this little thing really 
> qualify for NEWS.debian? (I just never had a chance to use it before).

Whether it qualifies is a matter of taste.  From my perspective it is
because if I type mc and I get only an error message from the shell I
would have liked to get this information beforehand.  I'm using this
alias on all machines I'm working on.  I have no idea whether this usage
is rather an exception or common practice.  In any case I do not think it
would have done any harm that people notice the new mc version more
prominently. :-)

> My doubts regarding this are because I'm not sure if NEWS.debian notice should 
> be issued when only user's customisations are affected (which may not be 
> considered under maintainer's responsibilities).

Its just a borderline case.  I'm doing this in a configuration file in
/etc for all users of the machines in question.  So it might hit Joe
Normaluser id admin would not notice.  But we do not need to discuss
this - your link solution makes it superfluous anyway.

Yuri, any veto for an upload to unstable?  If not I'll go for it this
evening?

Kind regards

        Andreas.

-- 
http://fam-tille.de