Re: AMD64 packages not in sync with i586 ones

Thierry Vignaud wrote:

> Jure Repinc <[email protected]> writes:
> 
> 
>>When reporting bugs and reading the Changelog mailing list I noticed
>>that a lot of packages for AMD64 are not at the same version as the
>>one for i586. A lot of them lag behind and some of them are a couple
>>of versions back (the latest package I noticed was QtiPlot).
>>
>>It would be nice if someone could resync all the packages for AMD64 so they 
>>are in line with the ones for i586. It is a bit hard to give correct feedback 
>>on problems if there is not latest packages available.
> 
> 
> there're bots for that but some packages are buildable yet on x86_64.
> the future will be maintainers only building srpms and the a bot doing
> the actual i586 & x86_64 builds and reject packages that don't build
> on both.

The problem is that for the future we have to pass trough the
present and thus the tree should be cleaned handly
(also consider that rebuilding bots are at initial
stage and often they aren't able to build big packages
because of other kind of problems [cluster, deps, exceptions, etc.]).

Secondly you have to wait that also developers/contributors
complete the training over the new system (including SVN).

The current tree suffers from these problems IMHO:

- developers have to babysit packages and subpackages once uploaded
to see effectively in tree, nevertheless the youri
have maybe accepted. Often this is very frustrating
and block your job for a long time, especially from
when you have to wait for a new packages A (that gone in
limbo), because package B that need to be built requires the
new packages A.

- there is no real control over the presence of all
the packages uploaded. I might update an .i586.rpm
without the .src.rpm or viceversa, or a package
X composed of X, X-subA, X-subB, X-subC and X-subD
you might get on cluster just X-subA and X-subB,
and other get lost.

- there are still a mix of mdk and mdv2007.0 packages. While
this is just cosmetic is not fine to see.

- xdg migration is still not complete.

- there is no way to remedy to uploading errors. Apart from
writing to maintainers and ask someone other to do so,
hoping the request is right, taken and executed.
This is blocking too.

All the 'blocking' problems might lead also to
mass escaping of contributors developers, who
might don't have all the time to following/pursing
the thing went wrong and for which don't have the
power or the training to remedy themselves, if not
complaining on ML that things are going wrong.

So, IMHO after 2007.0 final will be out this
things you be taken in consideration, instead of
waiting for the new building system as an oracle
for the new cooker, and abandon the old tree to
its destiny... :-)

Bye
Giuseppe.