Rawhide boot problems

[Lennart Poettering]

On Fri, 07.09.12 12:03, Kevin Fenzi (kevin at scrye.com) wrote:

> 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. 

Humm. I don't agree with this. As long as F18 is unreleased Rawhide will
be basically untested and I also wonder what testing it at this point
would bring, given that it right now is mostly F18 and very far from
F19, so why not test the real F18 where we need all testing focussed
anyway?

Committing this twice brings no benefit really, just doubles the work
necessary.

> 
> > > 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.

Well, eventually they will, but I think it would be good to do that as
late as possible so that people can focus on F18 to give it the detail
love it needs.

> > 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. 

Tests/checks are automized. Cherrypicking/commiting/building things
twice is not automized.

Tests are automated checks which help finding mistakes in what humans
do.

Making the human commit/build everything twice is just a way to increase
the chance that mistakes are made because humans suck at doing repetitive
tasks in comparison to computers which excel at it.

> > 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? 

We already have multiple commiters to the packages. But that doesn't
change the fact that you shouldn't throw people at a problem that should
be solved with a computer.

It's a simple fact that we have too little people working on Free
Software, and computers are much better at this specific task than
people, so it should be computers doing the job, not humans.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.