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  and the tip from our Mercurial repository (changeset > > 118) . 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 > 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 > >  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
Description: This is a digitally signed message part.
_______________________________________________ pkg-kde-extras mailing list email@example.com http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-extras