Re: bugs and patches in Debian
Hi Gabor,
On Fri, Jun 6, 2008 at 6:36 AM, Gabor Szabo <szabgab@gmail.com> wrote:
>> I've just seen the new metrics in cpants, great work!! I hope that
>> these leave the experimental status soon :)
>
> I think we need a few things to fix till then.
> One of them is making sure the links we add are not broken.
> for example what I reported earlier:
> http://cpants.perl.org/dist/errors/Text-CSV_XS
> Fur Tux - the maintainer who is very CPANTS aware - took about 20 minutes after
> the results started to arrive to ask how to find out more about the patches...
First of all, kudos to such a responsive author!
This was really a rare corner case, because we are in the process of
renaming the package to fit upstream naming. In any case, this has
made me see a problem with the current info: I'm not telling you if
the package is in one of the uploading queues. You see, in Debian
packages go always thru an "incoming" queue, where can live a few
hours before reaching the archive; also for new or renamed packages,
there's a manual queue called NEW, which can take a few days to get
processed. Text-CSV_XS is in fact uploaded with the version you see,
but it's currently in NEW; so most of the links you can generate are
broken as of now.
Maybe the best would be to provide an extra field indicating the queue status?
If you see that a package is in NEW or INCOMING, you could generate
different links, for example:
http://ftp-master.debian.org/new/libtext-csv-xs-perl_0.45-2.html
http://incoming.debian.org/libpoe-filter-ircd-perl_2.38-1_i386.changes
For packages in incoming, there's not much problem, because they're
already in the archive, only lagging the last version.
> So we need some good way to direct the CPAN authors to the details.
>
> For now, it might be enough to leave out all the modules (or at least the links)
> that are marked "not-uploaded" in their CPAN_vers field. Still we'll need some
> explanation on how to find out more information and what does that
> "not-uploaded"
> mean.
The meaning is clear here: we're working on it, but we aren't
finished. You can still see their status in our SVN repository and
maybe in the relevant WNPP bug page (where the intention to package
something is expressed).
> It would be also great if you could add the rest of the CPAN distros in Debian
> to the list. We can agree on another column "status" with a value sg like
> "individual-maintained" (you decide on some meaningful value)
> that will indicate for us that the links are meaningless.
> For such cases too we need some text to direct the CPAN module developers
> how they can find out more about their module in Debian.
I though a lot about this. The problem is that for group maintained
modules, we have already most of the data gathered automatically. For
the rest, well, it's not much that I can do without months of coding
:) I could surely provide you with debian version (and infer cpan
version), and number of open bugs. Patches will be much much more
complicated. Even CPAN_dist won't be an easy one, but it could be hand
generated once as an index. Do you think this would be useful enough
for you?
> Actually maybe the value "not-uploaded" should also be in that separate "status"
> column and not in the CPAN_ver column.
CPAN_ver was meant to be latest version uploaded to Debian, as I
understood you, so having something different than not-uploaded would
be incorrect, IMHO. We could add a second column indicating latest
CPAN version being worked on, if you want.
> In addition we need to indicate somehow if the
> has_no_bugs_reported_in_debian, has_no_patches_in_debian and
> latest_version_distributed_by_debian
> have any meaning to a module. That is, right now these fail in 2 cases:
> 1) when they really fail
> 2) when the module is not even in Debian.
> We will need to indicate that on CPANTS - but this is our issue.
Not my issue, but those can be safely ignored if the present in debian
tag is not there, IMHO.
> BTW I just though about something that might be interesting.
> I guess you people encounter modules that you would like to distribute
> but cannot for some reason. Maybe you have a place where you store
> this information
>
> "Module-X, version-y has been checkked and we cannot redistribute it
> because of Z"
>
> If you have such info it might be interesting to include that too and
> display on CPANTS.
Yes, certainly. But the problem is that we don't have that information
gathered, sadly. We you find something that's non distributable in
Debian, you just forget it. Next time somebody wants to package that
has no way of knowing somebody already tried. It would be a good idea
if we had this.
Related to this, there is an issue that we'd love to see corrected
upstream: packages with _some_ undistributable files. What we do is
just remove those files on each new release; but it would be nicer if
we don't have to. THere's not an easy way to determine this, nor it's
uniform. But there's a convention of adding a "+foo" postfix to the
version in those cases, +dfsg being the most used one. You can take
for example libpoe-component-irc-perl, which I had to repack to remove
copies of RFCs, because those are non-free in Debian.
--
Martín Ferrari
Reply to: