Hello > > Yes and it is nice to have meta data (the dgit things) rerpresenting > > the packages which can be shared between derivatives.
> I don't understand what you are referring to here. It seems to me but I can be wrong that the dgit informations stored under .git/dgit are sort of meta data which point to git ref corresponding to packages uploaded into Debian. Is it possible for dgit to allow pushing to another derivativ instead of Debian from the same repository ? > Are you saying that your source packages contain things that your git > repositories don't ? This comes up occasionally, and I will say again > what I have said before: I think this is wrong. Yes in my case I consider the configure.ac a source file, but not the configure script generated by autoconf. > You should have a single notion of `source code'. To borrow from the > GPL: the source code is the preferred form for modification. Exactly, the prefer form is the configure.ac and the makefile.am and not the Makefile or the configure script > Either the file (`configure', say) is part of your source code, in > which case it should be in the source package and in the git > repository; or it is not, in which case it should be absent from both. ok, so you just say that the git repository used by dgit-repo contain all the files that we obtain using dpkg-source to extract a usual debian package. We should call this an integration branch right ? > > So we need to agreed on a convention in order to let the upstream do the > > job of integrating their work in the Debian archive. > > Or at least to prepare something which could integrate the Debian archive > > in the end. > I don't understand. In fact I try to understand how we should use dgit at work in order to let developpers do the integration work by themself. We want to put the debian packaging in the upstream git repository and generate and push directly a package from this repository to either a local mini-build (PPA) or the Debian archive. > In git terminology, the tree objects in the dgit view contain the > upstream source code. > dgit should propose a sort of PR (via email) in order for the > upstream to propose the integration of its prepared package into the > repository. something which is done for now via mentors, maybe > I don't understand. I was thinking that an upstream should have work on his own PPA managed with dgit or new ppa tool, prepare internally a package then request for sponsoring this kind of tool should propose a sort of PR generator which should make it trivil to create a RFS RFS and send the email with all the informations necessary for a DD to review the code and uploading with just a dgit push. The way dgit get the proposed pacakge is indeed not clear :) > > does dgit propose to intégrate also the pacakges on mentors > I think you mean `are packages on mentors.d.n visible to dgit'. > The answer to that is `no they currently are not'. > The main part which is missing there is a git server suitable for this > use, but also the mentors workflow is rather unusual, because packages > uploaded to mentors.d.n are not in a suite in the same way as packages > in the archive. but we can apt-get them so they are available in a suite located in the mentors PPA ;) The history is not also linear, becasue you can upload two times the same package version but with different content. > It might be possible to in principle for dgit to present a view of > mentors. But, I wonder if that would be a waste of time. It would be > much simpler for the mentors and mentees to simply exchange git > branches and not bother with source packages at all. Except that I find it more convenient to get the source package and feed directly sbuild with this. this force the menteed to learn how to build a package. > The git branches could easily live on alioth (less of a security > problem than having the dgit repos on alioth, since the sponsor is > going to double-check them anyway). > I don't know what mentors and mentees would think of that. > mentors.d.n would need a way to represent a git-based sponsorship > request. Did we had some document or preliminary tought about how to integrate the packaging into uptream. something we should let them tought that the debian packaging is not something that difficult and can be part of their developpement effort. After all upsteam are integrating by them self into travis, readthedoc etc... It is e pity to see that Debian is not something where developpers thought they could host their code and integrate it into the platform. It seems to me that the debian packaging is something which looks like too complicate We should help upstream create a debian directory and integrate it into their developpement process. (continuous integration, ...) > If you are the maintainer of the package in Debian, and you are using > source format `3.0 (quilt)', then you have implicitly committed to > maintaining your package as a linear sequence of patches on top of > upstream. Merging from upstream branches in your git history is not > consistent with that. ok Fred -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150729165740.ga1...@synchrotron-soleil.fr
