[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Feasibility of backports?



On Thu, Mar 22, 2012 at 09:28:13AM +0100, Joachim Breitner wrote:
> Hi,
> 
> Am Mittwoch, den 21.03.2012, 17:01 +0100 schrieb Iustin Pop:
> > > ok, leaf packages are less of an issue. I kinda dislike to single out
> > > packages instead of treating all of them consistently.
> > 
> > I understand, and I agree with that. The question is if we have the
> > manpower to maintain backports of all packages as a whole, instead of
> > cherry-picking what's needed. Over the life of squeeze, I would guess we
> > probably need just (random guess) 20% of the packages backported.
> 
> That’d be 80 packages, that is quite a lot.

Ack. Was random number, though :)

> > > But this is Debian: If you want to invest the work, you can decide how
> > > to do it. So you are welcome to proceed that way and I won’t hold it
> > > against you :-)
> > 
> > Heh :) I'm just trying to understand what is the simplest way to get N
> > packages backported, where N is a small number.
> > 
> > A policy/technical question now: let's say we have backports for one
> > package (either just one or out of many). With git-buildpackage, I'd
> > just use a bpo-squeeze branch, which would be trivial to setup. How does
> > this work with darcs? I'm reading http://wiki.darcs.net/BestPractices
> > and it seems to say it doesn't support _any_ kind of multiple branches
> > in one repository?
> 
> No, in Darcs, a repository is a branch (in a way similar to SVN, where
> branches are directories in the virtual SVN tree). So what I did for
> expeirmental is to clone the repo and put it
> in /darcs/pkg-haskell/experimental – you can do the same
> with /darcs/pkg-haskell/squeeze-backports.

Ah, I see, one repo/directory per package under that?

I would guess there's no nice merge/cherry-pick between the repos then.
Not speaking down on Darcs, just that with git-buildpackage this
workflow seems more mature. On the other hand, upstream sources not kept
in Darcs, so it is simpler in this model, and you don't need to merge
that much.

> No support from PET in that case, though.

Ack. I'll try my hand at one or two backports then, and report back my
findings.

Thanks a lot for all the information!

iustin


Reply to: