[Pkg-kde-extras] KVIrc 4.0.0~svn3240-1 now really ready for upload

[Raúl Sánchez Siles]

  Hello:

  Excuse my delay, but I've been off all the weekend and I needed some time to 
catch up. FOA, Mark, thanks for the upload. We appreciate your interest on 
this.

El Domingo 07 Junio 2009, Mark Purcell escribió:
> On Friday 05 June 2009 20:48:59 Kai Wasserbäch wrote:
> > If you want to build the package yourself, you need revision 3240 from
> > upstream's SVN [0] and the tip from our Mercurial repository (changeset
> > 118) [1]. Then combine them and build with dpkg-buildpackage.
>
> Hi Kai & Raúl,
>
> As discussed on IRC I have uploaded your kvirc to unstable as I was pretty
> happy with the quality of your packaging and you seem to have a good handle
> on Debian requirements.
>
> One comment we did discuss on IRC briefly is your choice of Mercurial for
> the Debian component.
>
> Whilst I don't have any specific issues with Hg, it does make ways of
> working more difficult as kvirc is the only kde-extras package in hg and a
> lot of the ways of working such as checkin/ checkout building, taging etc
> are thus different to the rest of kde-extras.
>
> If you guys had a friendly DD working in hg with you this probly wouldn't
> be an issue, but given that kvirc needs sponsorship for upload to Debian I
> recommend that kvirc conform with the built up community of practice[1]
> around svn.debian.org for kde-extras.

  I think you deserve some explanation as why mercurial. Reason is quite 
simple: curiosity. I wanted something that allowed me working offline on this, 
and since I didn't like much of git insanity I decided to go with mercurial. 
However I did want to keep followable work somewhere and I soon relied on 
hgsubversion which is a mercurial extension that acts as a frontend to SVN.

  Even hgsubversion was experimental it worked quite well, till ABI with 
current released mercurial version broke. I then hold the svn updates and 
started working with pure mercurial and that's when Kai went in. I've never 
considered dropping SVN updates just that I didn't devote the time to fix 
hgsubversion. hgsubversion is planned to be fixed for July, when Mercurial 1.3 
will be released after that, the extension will be more stable and maintained 
for the stable mercurial release as well.

  If you are not happy with this dates I can manage to get some fixes before. 
because I think it is very important that people can keep up to date with  
what happens with development in an easy way. Anyway, I think packaging is in 
a pretty good shape, with the help of Kai, for sure, so I doubt it will be 
needed to do much work until real kvirc 4.0.0 is actually released. There's no 
formal date for this, upstream says soon, but can't confirm.

  We will be trying to improve package with what the TODO.Debian file states, 
but this has low priority by now, IMHO.


>
> Again this isn't a comment on the pros and cons of a DVCS such as Hg, but
> rather what we know and are familar with working with.  However the
> advantages offered by a DVCS I think are outweighed by using a toolset
> which we are not familar with in kde-extras. Of course some sort of a
> README-hg for kde-extras may address some of these issues, but I don't
> think doing kvirc a different way to the core makes a lot of sense for team
> maintenance.
>
> Mark
>
> [1] http://svn.debian.org/wsvn/pkg-kde/kde-extras/README

  Once again I agree with you. I didn't thought of anything like the kde-
extras README which I hadn't dive before. I think the documentation there is 
way helpful and we can manage to create a similar file on the mercurial kde-
extras repo. I think this step and keeping svn in sync with what happens on 
mercurial repo could fulfil the problems so far, with maybe some minor glitches 
which will eventually disappear when we take a further decision like dropping 
svn, mercurial or we move to git :D

  Mentioning git is partly a joke if it weren't for it's increasing usage in 
the Debian project. I'm familiar with git, but I prefer mercurial. And this is 
no enforcement, but preference that, as you can see above, I'm flexible with.

  Now about the Kai's mail and Mark's reply.

  As Kai and me have been talking on IRC, the filelist.txt problem is upstream, 
since an out-of-tree build system shouldn't place files into the source tree. 
We will discuss this upstream. I don't really know how you end up with those 
files, I don't even think it's important to tackle this unless you are curios, 
in that case I'm sure Kai could shed some light. Quite probably using a 
clean/kvirc:: target could workaround the issue acceptably.

  Regarding hg-buildpackage, yes, we all would like that would work, but it is 
not likely developed anymore, maintained by Debian QA Team, removed from 
testing and stable, crammed of bugs and if you think that's not important, 
take this: it's programmed in _haskell_ Those are the reasons I hadn't used it 
so far and I didn't even thought about using it, but now I feel curious :P

  Regards,

-- 
     Raúl Sánchez Siles
----->Proud Debian user<-----
Linux registered user #416098
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-kde-extras/attachments/20090608/fe4ec3a5/attachment.pgp>