Re: Rawhide
On 11/05/2012 01:12 PM, Jaroslav Reznik wrote:
----- Original Message -----
>
> Le Lun 5 novembre 2012 10:45, Dodji Seketeli a écrit :
>
>> Just having a dedicated Rawhide Swat Team of die hard volunteers
>> who
>> could spot issues early, file more bugs, gently push for fixes in
>> Rawhide and last but not least build a kind of "esprit de corps"
>> among
>> those who suffer Rawhide breakages for the greater good would be a
>> great
>> start, IMHO.
>
> There is already a pool of rawhide users.
> Rawhide bugs are already reported.
>
> The problem is not here, the problem is maintainers that deliberately
> ignore bugs with rawhide in them (usual excuse and motto are "Rawhide
> eats
> babies", "I'll test when Rawhide is more stable", no empathy for
> other
> maintainers that can not test because your problem is breaking their
> test
> process). They hope the problems will go away before branch time, and
> then
> cry they get too little time to fix stuff after branching when the
> very
> same problems hit alpha testers, or badger the reporters to file a
> new
> report at branch time without even checking the information that was
> provided before and assuming it is necessarily stale.
>
> All the systemd problems were reported in Rawhide way before they hit
> branched. If they did hit branched it's not because reporting was
> lacking,
> but because there was a lack of social pressure not to let Rawhide
> rot
> (with easily predictable consequences).
>
> When systemd inclusion was deferred in stable because it was not
> ready and
> no service had been migrated there was *no* effort I could see to fix
> the
> problem in Rawhide and systemd hit the next branch time with all the
> problems that justified initial deferring intact.
This is a problem - when developers do not work first in Rawhide and
do not push back to branched (or push into branched from Rawhide if
it's on time). We talked about it in the last Board meeting, one idea
was to block in Bodhi any updates where Rawhide version < update
version.
+1
Changes really need go to rawhide first and then where applicaple,
pulled to branches. If it feels painful, that's quite possibly a symptom
of being out of sync with the development window. The current situation
where branched tree gets ALL the attention when present is much like
flipping back and forth between left- and right-handed traffic rules:
much chaos, many collisions and lost bits and pieces ensues.
> Someone wrote in this thread that Gnome updates were painful in
> branched.
> Well they are horrific in Rawhide. If there was some effort to make
> them
> only painful in Rawhide they would not be horrific in branched. (this
> is
> called a 'virtuous circle').
>
> IMHO it was a huge mistake to synchronise Fedora releases with GNOME
> releases instead of synchronising Fedora branch times with GNOME
> release
> times. That's idiotic and means there is no time Fedora-side to do
> any QA
> and fixing before pushing a new GNOME release to users.
I think there's some sync between GNOME and Fedora releases - I already
proposed F19 schedule - 3.7.90 is a week before branching, and before
Alpha, 3.8.0 release precedes Features 100% complete and thus it goes
to Beta. Or are you talking about having final even before branching?
The current process allows us to influence (in some extend) development
of GNOME based on Alpha release etc. And yeah, it's probably not enough.
Its easy to see why eg GNOME wants to sync with Fedora the way its
currently done, but such massive packageset updates in branched
invalidate much of the earlier testing.
The stabilization period (ie going from alpha to final through X number
of intermediate steps) of a distribution and upstream software projects
are fairly different in nature: In a software project its about fixing
regressions and bugs in newly introduced features. A distribution
stabilization is about integrating the hundreds and thousands of
individual components to something coherent, and doing that is not
really possible if the components keep radically changing.
- Panu -