Packaging Process Question

[Just17]

I wish to try to understand why some package updates seem to appear quite quickly (in testing or main repo section) after a packager has updated them and sent them 'to dropbox', while other packages seem to linger in some limbo for a variable length of time.
A similar situation appears to apply to some new packages .....  some appearing quite quickly after being packaged and others not.

To illustrate what I mean I will take two examples .....  and I choose these two only because I have personal use for the packages and for no other reason ....

Example 1.
                 XBMC Ver 12, updating from Ver 11.
Usually updates take a few days after packaging, to appear in the public mirrors, being (I understand) sent to PASS repo first.
The update was sent 'to dropbox' on or before the 3rd Feb ......  9 days ago.
http://www.pclinuxos.com/forum/index.php/topic,112826.msg964342.html#msg964342

Example 2.
                Guvcview .......  the updated package was being tested in September 2012 ......  apparently the repo version was never updated .....  and it was again submitted 'to dropbox' on 6th Feb
http://www.pclinuxos.com/forum/index.php/topic,109623.msg965007.html#msg965007

As of this morning here, neither of the above updated packages has appeared in the public mirror.


I don't know what question to ask ......  I am just trying to understand what happens that causes some packages to be delayed ....  or maybe forgotten about .....  or whatever .....

In addition, maybe someone can let me know what determines if a package goes from 'dropbox' to testing (which is not on PASS I understand) or directly to a main section.
Are packages with small incremental updates treated differently to a package with a major update?

I feel sure it can be rather frustrating for someone who has requested a package, and had that package picked up by a willing packager, completed and sent 'to dropbox', and then not see it appear for a considerable time.

An explanation of the process and the criteria for decisions might help understanding of the difficulties being met.

Thanks.

[sling-shot]

Probably 64 bit is what is taking up most of the available developer resources now.
Incremental updates or bugfix updates would probably be taken up fast due to their ease or importance.
Sometimes packages may depend on others which are not yet available.
These are just my thoughts.

------------------

I am just thinking would be helpful to have a new official testing thread posted to the Testers section of forum whenever a new package lands in Testing or will it just be too much overhead for too little gain?
The positive will be a single thread for locating all bug reports about a package and probably more motivation for registered testers to post feedback and speed up movement of packages into stable.

[Just17]

Probably 64 bit is what is taking up most of the available developer resources now.
Incremental updates or bugfix updates would probably be taken up fast due to their ease or importance.
Sometimes packages may depend on others which are not yet available.
These are just my thoughts.

The two examples I used don't seem to fall into the categories I highlighted above ....  they have been packaged and sent 'to dropbox' for some considerable time.
I haven't seen either in the testing/test sections of 32/64 bit.

So there must be some other cause of which neither of us is aware.

Hopefully someone can enlighten us.

[muungwana]

being able to build from sources has its perks.

I tried xmbc 12 by building it from sources and it doesnt seem to work well for me,i tried rc3 previously and got the same problem.

Some videos play fine,others play without sound and video images move slowly.

Didnt use it long enough to investigate it plays fine with what video formats and it doesnt with what and moved back to version 11 since it works as expected here.

I have also seen packages taking an unusual amount of time to show up on occasions.There is talk for example that we will get KDE 4.10 when its at 4.10.x and that means in couple of months.

The reason i got for myself is that there are too many packages to be build,processed,tested and finally pushed to the public and there are not enough people to do QA on them.

For example, i am certain there is atleast one package that has been sitting in testing for a while now and nobody is testing it and then 7 people will report 11 problems about it when it hits the public. High standards and with lack of enough QA manpower is a reason for long delays at times,thats what i think.

[Just17]

Yes I can well understand packages sitting in test/testing for some time awaiting sufficient feedback to be sure they are reasonably well tested.

The cases I mean do not appear in test/testing at all .......  so how can anyone give feedback? ......  yet they have been packaged and are marked as such in the request section.

It seems some fall 'between two stools' ......  or there is some specific reason they don't appear in test/testing of which I am unaware.

[muungwana]

Yes I can well understand packages sitting in test/testing for some time awaiting sufficient feedback to be sure they are reasonably well tested.

The cases I mean do not appear in test/testing at all .......  so how can anyone give feedback? ......  yet they have been packaged and are marked as such in the request section.

It seems some fall 'between two stools' ......  or there is some specific reason they don't appear in test/testing of which I am unaware.

I am not a packager and i dont know the details of packaging but i think a packager creates a package locally and then send it to "drop box",then the package get rebuild again  by somebody else who then send it to testing or straight to the public.

When the package is "sent",it may get stuck if for example it builds in 32 bit but not in 64 bit and a decision is made to push the package when it build on both.Or maybe there are too many packagers to process and some take a back sit or maybe a decisions is made to build a package against an updated library and the library isnt build yet or maybe other life concerns takes most of the time of whoever does the QA before pushing them to testing or to the public.

The reason may be numerous but i think lack of time and resources is the biggest one.

Since the time a package is reported as being "sent" does not reflect when the package will actually appear in testing or in public,maybe there should be some sort of a change to how these "sent" packages are reported to the public.

[Just17]

Thanks muungwana,
                              and although it might be unfair, but as I have mentioned two particular packages, I would like to see if those reasons apply to them.
  It seems to me the possibilities you mentioned do not really apply here ....  although I wish to acknowledge that those possibilities likely do apply in a lot of cases.

IF my interpretation is correct then there must be some other reason in those two cases ....  but of course I am open to correction on my interpretation.

Yes, I agree, that when someone makes a request, and the thread is closed with the notification that the request has been packaged, there would be an expectation of seeing that package appear in some section of the repos within a week or so. That, I understand, would be the expectation .....  and after some time in testing, and feedback on the package there would then be some expectation of it moving to one of the standard sections of the repo.

Those expectations are not, apparently, valid.
So, as you suggest, maybe something further is required to alleviate any frustration from undue expectation.

On the other hand, if we know why there are delays in the system, maybe some resolution will become obvious.

At this time, none of us appear to know what is causing the seemingly different treatment for different packages.
Maybe understanding those reasons would help everyone.