Re: 185 Packages that look orphaned
Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <jfs@computer.org> writes:
> (Don't CC, I'm in -devel)
>
> On Wed, Jan 28, 2004 at 03:28:50AM +0100, Goswin von Brederlow wrote:
> > > > lmbench
> > > Ditto.
> >
> > # The current maintainer is looking for someone who can take over
> (...)
> > to be co-maintainer in order to help the actual maintainer. Please
> > see bug number #216883 for more information.
> >
> > Is that still true?
>
> Yes, it is. A RFA: is disctintly different from an O: however.
>
> > > Now, I really don't remember seeing a mail on d-announce saying that
> > > autobuilders would not build non-free packages, but maybe I've missed it.
> >
> > It was mentioned in Bug number #216883 of yours so you must have
> > forgotten about it since last October. But a number of DDs are
> > surprised to hear that so your not alone not knowing.
>
> Notice that I did not said I didn't know about this, I said I have not seen
> it mentioned "officially" (either in d-announce or in our documentation).
I will see if that can be rectified.
> > Some packages can't be autobuild for legal reasons. All of those are
Some as in some of non-free/contrib, not just from the list.
> > in non-free. There is no flag in the source packages saying what can
> > be legally build and what not and no list is provided otherwise. Also
> > some people don't want to support non-free software.
>
> The funny thing is that most of the packages you mentioned from me (save
> for lmbench) have been autobuilt at some point and _no_one_ has ever asked
> me if there were legally reasons not to do this. I can understand that
> there might be _some_ packages that could not be autobuilt, but I fail to
> see why this would be applied to all packages, even those that have been
> already autobuild. Notice that the builds of my packages (and probably of
> many other DDs) have not been removed, so those "legal" reasons don't seem
> to be of much concern, but more of an excuse.
At some point someone decided that it would be best not to build
contrib / non-free by the buildd. That someone convinced the
wanna-build maintainers (if he wasn't one of them) not to autobuild
them. After that no buildd ever got asked to build the packages.
Or wanna-build didn't include them from the start and you just see
build that pople have manually added to the buildds own build list at
some point in time.
> > I think what would work best currently is if you get a comaintainer
> > for every arch you can't build the package on or at least a steady
> > group of sponsors. If noone is willing to build the package you can
> > file a bug against ftp.debian.org to get obsolete versions removed.
>
> No, I can still keep it the current way and only provide support for i386
> users running unstable, which is really fine by me too, BTW. And if someone
> comes over and asks why is 'X' not available/updated in his favorite
> architecture 'Y' I will forward him to the mailing list for that arch.
You are forgetting the intrests of Debians users in general here.
There are a lot of users that don't use sid for various reasons and
you deny them your package for archs you support. Can you live with
all those poor users out there being deprived of your good work?
Your lmbench is the top package that just needs to be build for the
missing archs. But since its up for adoption there is no blame
there. So please think about this in the general case of packages and
not just your three packges mentioned. Forget about your packages for
a moment, relax and imagine you were a stable user. Now ...
The maintainer should now best if a non-free/contrib package can be
build for debian by others or not and if it needs to be build on some
archs to keep current. If he sees someone that previously helped
building the package lost interest wouldn't it be good to ask for
someone new on debian-<port>? It takes maybe 5 minutes to check a
package and to write such a mail. 5 minutes per package every 3 month
or at least once a year. Is that so much to ask. Wouldn't you (as
user) ask about whats up when you see that hapening?
> So, you see, there's really some in-betweens in this situation. The fact
> that those packages are non-free mean that they are low priority for me,
> I will probably not fix bugs in them if there are serious bugs in other
> packages I maintain or co-maintain. That is not to say that I won't do it,
> it's just that there are other 62 packages that are higher in the listk.
> Given infinite time, they will get their share too.
>
> Since probably many others maintainers have not rejected NMUs or help from
> interested parties I don't see how this situation is better than handing
> them over to our (overloaded?) QA group. Matter of fact, I would not like
> to see QA people dedicating time to non-free packages when there are still
> RC bugs open.
>
> Regards
>
> Javi
Never said I want to just dump them all into the lap of the QA
group. Most non-free/contrib packages in fact just need a little nudge,
need to have some obsolete debs from unmaintained archs removed or
need someone to compile it for their arch to get into sarge. Now I
know your position on your packages and can act accordingly.
MfG
Goswin
Reply to: