Proposal for package workflow/packaging
David Paleino wrote:
> I really like SVN instead. I just cannot understand git de-centralised
> architecture. But it's time to learn it :)
in the here proposed way, it's not used de-centralised at all, but as
centralised as you're used to with svn.
>> 3. Basically, everyone handles packages freely on his/her own, from the
>> initial upload of a new git repository on alioth, up to the point where
>> the package just needs to be, finally, uploaded by someone.
> Uhm... why?
this was probably bad worded from me. i'll try to clarify.
> In other teams I'm in, the package, before being uploaded, passes a variable
> number of reviews. This because we all have a checkout of the (SVN) repository,
> and a "svn up" just shows what changed. Thus gives us the chance to spot errors
> in packaging earlier and easier.
yep, same here.. the package should get pushed to alioth and everyone
sees it on the repo (and the commit mails on forensics-changes at l.a.d.o
:). everyone should do commit on it regardeless if he is uploader or
not, to help with the packaging.
my intention was to say, that i'm not doing everything (rather the
oposite actually :), because for the first few packages i've done the
initial checkins and asked people temporarily to not checkin initial
upstreams on their own (which is not needed anymore as the cheatpage is
> This is another side I don't understand about git. Why single-person
> repositories, and not team-wide? (I mean, like
git does not support partial checkouts. in svn, you can checkout e.g.
svn.d.o/svn/$team/trunk/$package to get one package. in git, a checkout
always contains everything recursively. therefore, one does 'one
repository per package' to keep the repositories smaller/tighter.
since git 1.5, there are submodules supported, means, one can have a
'super-repository' containing normal repositories. but it doesn't make
any difference at all for the operations you do - except that you can
checkout all submodules at once (but for that, one can have simple
script to do that anyway).
> As a sidenote: someone on Debian-Med (Morten Kjeldgaard) proposed a "Full RFC822
> specification", which then he added on that Wiki page. I believe we could use
> it, but it's probably more verbose than necessary. Until now, I've just used
> the "Files/Copyright/License" format, i.e. not using RFC822 fields.
yep, same opinion here. the full-rfc822 is for the moment a bit too
verbose to me. maybe, debian can focus on one mandatory implementation
>> * generall things like having 'slick' debian/* files (look at e.g. the
>> rules files of some of the already uploaded packages to see what i
> I can't currently find anywhere the .diff.gz: I've only found
> the /new/$package.html pages for team packages. Am I missing something?
you can look at the git repository, or, as i keep an archive of packages
i ever uploaded, they are also present at:
>> * using stgit for handle upstream modifications/patches.
> I'll google for this.
not really needed as of now, as none of the previous packages had done
any upstream modification (outside of debian/*). will write/include it
into a/the cheatpage in the next days.
> Should we add that page to forensics.alioth.debian.org (or to our Future
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann at panthera-systems.net