----- 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.
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.
(two high-visibility examples anyone can understand, not necessarily
the
worst offenders and systemd people at least seem to have improved
their
workflow a little over time)
Adding time to the end of the circle is compounding the problem, not
fixing it.
Another thing would be use more the GIT workflow while building stuff
for Rawhide. For example - it takes quite a lot of time to build the
whole KDE stack for Rawhide and of course, this leads to breakage -
and if upstream decides to push back release when we're in the middle
(it happened) we were screwed. So use own build target, merge/push
to Rawhide once it's done. Question is how demanding would this
behaviour be for infrastructure (if used more often by more teams,
or even required by a policy).
R.
--
Nicolas Mailhot
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel