Rawhide boot problems
kevin at scrye.com
Fri Sep 7 18:03:48 UTC 2012
On Fri, 7 Sep 2012 19:16:39 +0200
Lennart Poettering <mzerqung at 0pointer.de> wrote:
> On Fri, 07.09.12 11:00, Kevin Fenzi (kevin at scrye.com) wrote:
> > > I think our policy is that you should do rawhide builds, but at
> > > least some significant groups of packagers actively don't do
> > > rawhide builds. If that is going to continue, we should consider
> > > having rawhide inherit from updates-testing.
> > I'd like to propose the opposite:
> > Lets drop any inheritance between branched and rawhide.
> > Is it really that much trouble to commit/build in rawhide first?
> Yes, it effectively doubles my Fedora workload.
I don't think it doubles it. I agree it increases it some, but it also
adds a layer of smoketesting and doublechecking, so IMHO it's worth it.
> > Thats where you should be doing your development anyhow. Then, only
> > if all looks well, should you push to branched.
> Dude, I already have to look afer way too many distros at the same
> time. I see no point at all in developing two development distros
> simultaneously. As long as I don want my F18 and F19 version of
> packages diverge I see no point in doing everything twice.
But f18 and f19 _are_ diverging behind your package. Some of the time
you might not notice, but it's happening.
> It sounds really bogus to me to develop to distros at the same time
> rather than just focussing on stabilizing one of them and let the
> other just get a copy of my packages.
Think of rawhide as not another distro, but another packageset/check.
> I mean, I don't really like doing packaging work that much. I do it
> because it is necessary, not because it is fun. You know what is even
> less fun? Doing everything twice if things could just as easily be
> inherited automatically.
Perhaps you could try and find some package maintainers to do that work
for you while you work on upstream issues?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel