| 1 |
On Sun, 11 Jun 2006 07:33:19 -0400 |
| 2 |
Peter <pete4abw@×××××××.net> wrote: |
| 3 |
|
| 4 |
> On Sat, 10 Jun 2006 13:37:15 +0200, Markus Ullmann wrote: |
| 5 |
> |
| 6 |
> > 1) m-w / m-n requirement |
| 7 |
> > |
| 8 |
> > Only ebuilds that are reported to bugzie (valid bug#) and set to |
| 9 |
> > maintainer-wanted are allowed here as well as maintainer-needed |
| 10 |
> > ones. |
| 11 |
> > |
| 12 |
> > maintainer-needed are only allowed if they're removed from the tree |
| 13 |
> > and moved over to sunrise (and thus end up as maintainer-wanted |
| 14 |
> > again). |
| 15 |
> > |
| 16 |
> |
| 17 |
> Um, there are numerous "new" not-in-portage-tree ebuilds submitted to |
| 18 |
> bz which have been assigned to teams. However, they may still |
| 19 |
> languish. They were assigned by the wranglers, and not improperly. |
| 20 |
> Yet, for many reasons, the bugs wait. So, will there be a mechanism |
| 21 |
> for a contributor to get an ebuild uploaded to sunrise in this |
| 22 |
> circumstance? |
| 23 |
|
| 24 |
What those bugs are waiting for is a dev to step up and agree to |
| 25 |
maintain it. I don't see how sunrise improves that situation. The |
| 26 |
only way such a bug will be resolved if no dev is interested, is if |
| 27 |
someone who wants the package in the tree decides to become a dev - and |
| 28 |
that means demonstrating technical ability, and sticking around (not |
| 29 |
just dumping it in the tree then disappearing - in which case the |
| 30 |
package would likely get removed after a while anyway due to lack of |
| 31 |
maintenance). |
| 32 |
|
| 33 |
> I would also suggest having some sort of review process for inclusion |
| 34 |
> of m-n/m-w bugs. Some may not have any relevance (i.e. the program is |
| 35 |
> no longer supported, or the upstream project has been incorporated |
| 36 |
> into a new one, or the version of dated). Doing a blanket import of |
| 37 |
> m-w bugs could make quite a mess of things IMO. |
| 38 |
> |
| 39 |
> One of the terrific benefits of sunrise will be the cleaning out of |
| 40 |
> bugzilla. Nuking open bugs is an especially satisfying experience! |
| 41 |
|
| 42 |
Sorry, I don't buy that. Having m-w/m-n packages in the sunrise |
| 43 |
overlay cannot be sufficient to close the bugs in bugzilla. The bugs |
| 44 |
get closed when the package gets maintenance support from a dev and is |
| 45 |
put into the tree. Sunrise doesn't do anything to make that more |
| 46 |
likely. |
| 47 |
|
| 48 |
I also don't think that having large numbers of bugs open in bugzilla |
| 49 |
is a problem. The search facilities are quite capable of giving you |
| 50 |
focused lists of open bugs. If you don't want to see the bugs about |
| 51 |
m-w/m-n ebuilds, filter them out of your search. |
| 52 |
|
| 53 |
> Lastly, what about user contributions? Will users require some kind of |
| 54 |
> sponsorship in order to have their ebuilds posted? What will the |
| 55 |
> procedure be (or did I miss it in one of the hundreds of emails)? |
| 56 |
|
| 57 |
This reflects back on the primary objection to sunrise on gentoo.org. |
| 58 |
Your question is essentially, "who will take responsibility for it and |
| 59 |
put it in the tree?". Sunrise might help in getting ebuilds to a decent |
| 60 |
standard, and it might help some users to contribute, but it won't help |
| 61 |
if no dev wants to take on maintainership of the package. That last |
| 62 |
point is the only reason why m-w/m-n packages are not in the tree. |
| 63 |
|
| 64 |
-- |
| 65 |
Kevin F. Quinn |
Archives