Guillermo Vaya wrote:
After reading this thread, I just have an idea (maybe a stupid one):
People are willing to help, so why not share the testing part? I know
there is a testing repository but maybe there are people that just
want one or two packages to test. Maybe someone has a server where
squirrelmail is not critical and could help testing or/and making the
pkgbuild. So the testing part would be much quicker and it would be
easier to find problems.
It would be something where you can subscribe to the packages you
would like to help with, and have some kind of advertisement whenever
there is a new one for testing. It could be some kind of rss or
mailing list (or any other thing, I'm not sure which could be the most
apropiate). Also if one developer is really busy and can't get enough
time to make the pkgbuild, maybe he/she could pass the task for that
releasse to one of the people helping him test.
Anyway, as I said before is just an idea and maybe a stupid one.
Regards,
Driadan
Er....no, not a stupid one but rather the way it is already supposed to
work. People are supposed to be subscribed to the testing repo and
updating their systems to test the new pkgs. However, for those of us
that provide pkgs to the wider community (and that cannot have two
installations running) we have to stick to [current] and [extra].
Seeing as we are also some of the most active members of the community a
large part of the testing audience is unable to take part in the current
testing process. Very unfortunate situation that is! The burden of
testing should fal on others in this case but as many of the pkgs are so
unstable people are shying away, therefore testing is very slow.
Also you must consider the development team's closed doors approach to
the gcc4 and libtool projects. If the dev team would like the support
of the wider community in testing etc then maybe the projects should
have been undertaken with more emphasis on involving the community
rather than having the whole thing coordinated and discussed behind
closed doors.
Phil
Paul Mattal wrote:
Richard Golier wrote:
What to do if packagers don't update their pkg even after they've
been flagged as out-of-date for a long time? As an example take
links: Last Updated: 2005-04-04, ok i contacted dorphell on irc and
let him know, but still no update.
Or bluefish Last Updated: 2005-07-09. There have been 2 new versions
since then, pkg is flagged out-of-date and still nothing...
Are the maintainers so busy? I understand they may have a lot of
work, but replacing pkgver in PKGBUILD and compiling both of the
packages took me about 3 minutes, so it's not that time-consuming.
I have one response to this. Not a criticism either way, but more a
sharing of additional information.
For one, sometimes developers are that busy. As we all know, the cost
of "task switching" can often be one we sometimes can't afford --
even for a task that only takes a few minutes. Turns out my inbox is
filled with about 100 tasks that take 5 minutes right now.. so how do
I prioritize? The answer is that work has been really busy lately,
and I can't afford to do any of those 5 minute tasks, so none of
those is getting done right now. Maybe next week.
For two, replacing a pkgver in a PKGBUILD and compiling isn't where
it ends for a developer. One of the key things a developer
must/should do is TEST, at least basically, each version they
release. Bugs/incompatibilities get introduced into things all the
time. Each version of squirrelmail or motion I release, for example,
sits on one or two of my own production servers for testing for at
least a day or two (but usually a week) before I release it. This is
what guarantees quality releases for all of you out there.
Just trying to add some more perspective that might help you
understand why you haven't seen an update yet.
- P
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
_______________________________________________
arch mailing list
[email protected]
http://www.archlinux.org/mailman/listinfo/arch
