| 1 |
> Ok, I could understand that none of the mips team are online when I |
| 2 |
> want, but how about the bug mentioned above? One month I |
| 3 |
> waited/begged/threat!!! For what? For some lousy script updates, which |
| 4 |
> is not arch dependent anyway! |
| 5 |
|
| 6 |
There are lots of open bugs, sometimes they slip under the radar. And |
| 7 |
*never* assume scripts are arch independant. See more below... |
| 8 |
|
| 9 |
> Not every package that I maintain is tested by me! How can I test a dsl |
| 10 |
> driver when I have no such device! |
| 11 |
|
| 12 |
Do you have somebody in your herd test it that does have such a device? |
| 13 |
If not, you shouldn't be maintaining it. |
| 14 |
|
| 15 |
> I apply the good old rule that if a package has no open bugs for a |
| 16 |
> month, it will be marked as stable. |
| 17 |
|
| 18 |
This if fine if you can vouch that it works. None of us could say |
| 19 |
rp-pppoe works. What is more, just because it works on x86 doesn't mean |
| 20 |
there aren't problems with other arches. Even things like |
| 21 |
perl/python/<insert favorite scripting language here> scripts are |
| 22 |
included in this statement. If I remember correctly, ciaran even ran |
| 23 |
into a non-portable vim script at one point. |
| 24 |
|
| 25 |
That said, since you are the package maintainer, you should be |
| 26 |
practically the world's expert on this package. You should know if |
| 27 |
there are potential endian problems. You should be talking to upstream |
| 28 |
to find these sorts of things out. If you have full confidence that it |
| 29 |
should be stable on our arch, mark it stable. Seeing as you see fit to |
| 30 |
break policy and mark your dsl driver package stable even though you |
| 31 |
can't test it, then how is this any different? Keep in mind that I'm |
| 32 |
pretty sure there are developer machines available for (almost) every |
| 33 |
arch now. Package maintainers should use this resource for testing |
| 34 |
purposes. |
| 35 |
|
| 36 |
> If I would do things you way, in this moment net-dialup would have at |
| 37 |
> least 100 opened bugs with no one carrying about them. I urge you to |
| 38 |
> look in bugzilla to see how many rightfully complaints are there |
| 39 |
> regarding my work. Not as if I consider less about a dev who made a |
| 40 |
> mistake (only who do nothing, does no mistakes)... |
| 41 |
|
| 42 |
You are missing the point. |
| 43 |
|
| 44 |
> It is OK to want to make more than a simple compile test, but from this |
| 45 |
> to doing nothing when a fellow dev ask you to IS a big distance! A |
| 46 |
> convenient excuse, nothing more... |
| 47 |
|
| 48 |
Convenient excuse for what? Do you think we singled you out and said, |
| 49 |
"hey, I don't like that mrness...we're just going to ignore his package" ? |
| 50 |
|
| 51 |
> I didn't wanted to get so involved in this bug, but invalid bug reports |
| 52 |
> started by the transition from -r2 are killing me. In rest, what do I |
| 53 |
> care that your arch is outdated! |
| 54 |
|
| 55 |
I don't quite see what the big deal is anyway. When I looked, the last |
| 56 |
stable version of that package was from last november or so. If we were |
| 57 |
a year out of date or something, that might be a different story. We do |
| 58 |
have a script that emails all of the mips team with outdated packages |
| 59 |
from time to time, however we have a shortage of devs and time, so |
| 60 |
non-crucial stuff that none of the mips team uses like rp-pppoe |
| 61 |
typically gets pushed back. |
| 62 |
|
| 63 |
Steve |
| 64 |
|
| 65 |
|
| 66 |
|
| 67 |
-- |
| 68 |
gentoo-dev@g.o mailing list |
Archives