| 1 |
> Bugzilla is a tool for developers to track progress, not for |
| 2 |
> third-party distributions to track progress. You've forked the tree. |
| 3 |
> That's fine. The license allows that. But it doesn't obligate us to |
| 4 |
> adapt our tools to fit your purpose. |
| 5 |
|
| 6 |
I've done lots of version bump bugs over the years. my reasons for |
| 7 |
doing so may have changed. But the general process has not. Does it |
| 8 |
matter if I've forked? doesn't the package still need an update? |
| 9 |
|
| 10 |
> Your behavior on bug 260582 was clearly unacceptable. You |
| 11 |
> seem to think that we owe you something. Please re-examine your |
| 12 |
> premises. Donnie already told you he was working on it. Our job is not |
| 13 |
> to support your distribution. It is to make the best distro for |
| 14 |
> ourselves. In the case of xorg-server, that means getting something |
| 15 |
> into the tree that works. A masked ebuild will in this case be more |
| 16 |
> bother than it's worth because the mask would have to encompass a |
| 17 |
> bunch of other packages. Which leads me on to the next paragraph... |
| 18 |
|
| 19 |
this and all the cases given are examples, and perhaps my behavior was |
| 20 |
unacceptable. But I think the response to my bug was too. No gentoo |
| 21 |
doesn't owe me or regen2, a thing. It might, however, owe users |
| 22 |
something. I agree on committing ebuilds that work, that doesn't mean |
| 23 |
I don't have the right to open a bug and watch for progress reports. |
| 24 |
|
| 25 |
> In many cases that's true, but on average, the QA of the tree is much |
| 26 |
> better than overlays. |
| 27 |
|
| 28 |
I couldn't say... I suppose I agree yes on most overlays, but a few |
| 29 |
are supposed to be more 'exceptional'. the biggest problem is the bugs |
| 30 |
that result between ebuilds in the tree and those of overlays. like |
| 31 |
one I filed on virtual/perl-Mime-Base64. or like how inkscape won't |
| 32 |
build against 5.10, except with patches already in bugzilla, but both |
| 33 |
cases seemed to be one of 'perl 5.10 isn't in the tree so we won't |
| 34 |
fix' I think they should put it in before 5.10 is in the tree. put |
| 35 |
that's just me. |
| 36 |
|
| 37 |
> We Need Git. It would really ease the workflow of accepting user |
| 38 |
> contributions if users could just set up their own overlay and sent me |
| 39 |
> an email asking to merge their changesets. |
| 40 |
|
| 41 |
git's great. but I've actually found 'merging' changesets to be a bad |
| 42 |
idea from people. It can lead to some really sloppy commits, and |
| 43 |
merging is a less stringent review than cherry-picking patches. |
| 44 |
|
| 45 |
> You could |
| 46 |
> have made thousands of commits already, fixing a substantial amount of |
| 47 |
> the problems you've raised. |
| 48 |
|
| 49 |
thousands seem like a high number. I think I've been pushing an |
| 50 |
average one 1 patch per day since january to the tree (my tree). |
| 51 |
*laughing* I'm still the #1 contributor of git patches to funtoo. |
| 52 |
|
| 53 |
> This isn't a quick fix. |
| 54 |
|
| 55 |
> You'll have to work with people and |
| 56 |
> that can sometimes be frustrating. |
| 57 |
|
| 58 |
I already have to 'work' with these people, the difference would be |
| 59 |
what? how much respect I get? in gentoo land having @gentoo.org seems |
| 60 |
to mean something... if you don't have that, you seem to |
| 61 |
auto-magically get less respect, than you would if you did have it. |
| 62 |
|
| 63 |
> But you'll get to be part of the |
| 64 |
> development process and you'll get to work with the things you care |
| 65 |
> about. |
| 66 |
|
| 67 |
you mean I'll be part of 'a' development process and work on some of |
| 68 |
the things I care about. Obviously stepping on other developers toes |
| 69 |
seems to be a taboo. |
| 70 |
-- |
| 71 |
Caleb Cushing |
| 72 |
|
| 73 |
http://xenoterracide.blogspot.com |
Archives