[pkg-bacula-devel] Upcoming push to new git repo

Wed Apr 20 11:23:25 UTC 2011

Hi Luca,

On Wed, Apr 20, 2011 at 12:57:09PM +0200, Luca Capello wrote:
> Hi Jan!

Still, I prefer Hauke :)

> On Wed, 20 Apr 2011 09:59:25 +0200, Jan Hauke Rahm wrote:
> > As you can see, I rebased my changes before I pushed. There is now the
> > master branch with only the adoption and a first changelog entry.
> 
> Mmm, I do not see any rebase, or at least I do not consider that a
> "real" rebase: AFAIK you simply import only 4 changes, right?

I don't know about unreal rebases... If you compare the commits between
the old and the new repository, you'll see that I ran git rebase on it.
Anyways, yes, four changes, the others still to come in one or more
development branches (to keep master a bit cleaner).

> > If you guys agree, I'd like to use git-dch to auto-create
> > debian/changelog and it's setting should be 'id-length = 8' so we can
> > look up commits more easily later. I.e. NO changelog changes in
> > commits, but only before we upload (using git-dch -a for
> > instance). Ok?
> 
> I actually do not like at all this workflow, because I do consider an
> archive to be used without any Git-foo command, which means that
> debian/changelog entries are not updated when the modification is done,
> like any other ChangeLog.  What about commits which fix previous
> commits?  They should not be part of debian/changelog, given that there
> is no point in that, e.g.:
> 
>   <http://svn.debian.org/viewsvn/foo2zjs?view=rev&revision=272>
>   <http://svn.debian.org/viewsvn/foo2zjs?view=rev&revision=273>

I'm not sure I understand your point really. Thing is: if you commit
debian/changelog everytime you change something, merges, cherry-picks
etc. become a lot harder. And I'm not saying that git-dch's output is
definite in the end. It always needs tweaking.
And whoever has the git repo, has git log and doesn't need
debian/changelog to contain anything.

> And I see this workflow as a point of failure for those who would like
> (erroneously) to build a not-yet-released package and do not start with
> git-dch: the so-generated debian/changelog will be the old one, thus
> clashing with previous installations.

Therefor there needs to be anyone using the repository besides us in the
first place. Also, we can agree upon adding a dummy changelog entry
after a release with UNRELEASED as distribution. That solves that
problem and git-dch still works.

> OTOH, as I wrote in a previous email, I do not care and you can simply
> go on as you like.  I know that I have very strong opinions about how to
> deal with debian/changelog:
> 
>   <http://bugs.debian.org/517973>

I see. Well, we don't need to discuss this here anyways. :)

> Finally, if you decide something (with consensus or not, remember that
> Debian is a do-ocracy so people doing the work have the last word),
> please document that in a sort of policy, to be eventually added to:
> 
>   <http://pkg-bacula.alioth.debian.org/>

1) I don't like the do-ocracy stuff as much as everyone else as it seems
2) I'd like to have consensus of the people actually working here
3) I will NOT be the only one working :)

> > Please, everyone who wants to contribute, add youself as uploader and
> > once that's done we can upload 5.0.3-1 if we want. Anything that
> > *needs* to be included in a first upload?
> 
> I do not think we need everyone added as Uploaders: this should be done
> on a work-basis, i.e. as soon as someone works on the package on a
> regular basis (or she/he does an upload as a team member) she/he gets
> added there.  ATM you are the only one working on it (I do not know
> where José is with his work), so this should be reflected in the Debian
> package.  But this is a minor point.

Well, ok.

> > About #606262: I think we should indeed fix that in the first upload.
> > Then we create a squeeze branch at debian/5.0.2-3 and cherry-pick the
> > fix. Does anyone volunteer or do you want me to do that? Talk to me,
> > please!
> 
> I would say that we need to upload something ASAP, at least just for the
> new maintainer and/or the new version.  If you would like to include a
> fix for #606262 in the first upload, this should be OK, but given the
> situation as it is now (squeeze is out, so any harm has already been
> done), nothing will change if #606262 gets delayed.

Hmm, I'm a bit reluctant to let all autobuilders run on bacula just to
change debian/control. The bug states clearly that we are working on it.
No-one is going to steal bacula. :) But since my others changes are
quite heavy (and untested), we can of course upload 5.0.3 now and do
everything later on.

> > About my changes that were in the wrong repository: Since I already
> > rebased stuff, I'm thinking I can maybe make two or even three
> > dev-branches out of it to untangle different matters. We'll see.
> > Otherwise I'll push that branch soon.
> 
> I would say you should have used your old repository (please note, it
> was not "wrong" in a bad sense of term, it was OK as well, but not at
> the right place if we need more than one repository, as we do for
> bacula-doc...) as it was.  Nevertheless, you got the power, use it ;-)

Changed now anyways. Let's use the one that we (you ;)) wanted to use in
the first place.

So... all other contributors: could you please say something? Else I'm
going to upload bacula as it is in master.

Hauke

-- 
 .''`.   Jan Hauke Rahm <jhr at debian.org>               www.jhr-online.de
: :'  :  Debian Developer                                 www.debian.org
`. `'`   Member of the Linux Foundation                    www.linux.com
  `-     Fellow of the Free Software Foundation Europe      www.fsfe.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-bacula-devel/attachments/20110420/e63ac86d/attachment.pgp>