Hello Denis, On Tue, 2011-11-01 at 18:54 +0100, D. Barbier wrote: > On 2011/11/1 Adam C Powell IV wrote: > [...] > >> Hello, > >> > >> I just pushed a db/debian branch into upstream repository > >> https://github.com/tpaviot/oce/tree/db/debian > >> It will not be merged into our trunk, I pushed it there since I did > >> not know where to publish it. > >> It has been minimally tested, but needs more polishing. > > > > Great! I like that you've continued with the old OCC changelog. > > > > But I think it makes sense to do development of the package on the > > "official" Debian git server, to facilitate team management. In general > > when upstream creates a debian/ directory, it confuses things because > > there can be multiple "Debian packages" floating around. > > I fully agree. This branch will be deleted as soon as we can decide > of its final location. > > >> So, how do we proceed now? Do we change package names, as in this > >> branch? If yes, do we switch to a new repository? > > > > That's a good question. I could go either way: > > 1. tart a brand new repository, since it's a new package with new > > names -- but then start with a new changelog; or > > 2. Use the oce tarball as a new "upstream" on a renamed or cloned > > repository, or a branch, to more clearly show the changes > > between OCC and OCE. > > > > I think #1 makes more sense, particularly because it's perfectly easy > > for someone to "diff -ur" the two trees and see the changes, and we > > aren't trying to track patch-by-patch changes -- that's OCE upstream's > > job. We can leave opencascade.git in place, and start a new oce.git in > > the same place. > > Great, I also prefer #1. Can you please request its creation? (I can > also do it if you prefer)
I can go ahead and make it, I assume based on tpaviot-oce-OCE-0.7.0-1-g35b4691.tar.gz which I'll call oce-0.7.0.orig.tar.gz ( https://github.com/tpaviot/oce/downloads clicked on "Download as tar.gz"). > Are there some guidelines about the preferred git workflow when > upstream has a git repository? I don't believe so, as far as I know we just use the tarballs. > > Also, Denis, I think Conflicts is better than Breaks because apt will be > > sure to remove a Conflicts package before trying to install the new > > package; > > Okay. > > > and it would be good to indicate Provides as well to smooth the transition. > > This is IMO a bad idea because OCE is based on Opencascade 6.5.1, and > as you know, OCCT releases are not compatible. > > > When OCE enters unstable, we file important (future FTBFS) bugs against > > OCC's rdeps. Then when OCE enters testing, ask the ftp-masters to > > remove OCC from unstable and testing and turn the unclosed important > > bugs to serious ones. > > > > Sounds good? > > Yes, thanks. Great. I'll get started in the next couple of days. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/
signature.asc
Description: This is a digitally signed message part
