Re: bugs and patches in Debian
I know I am PITA, but would it be possible to start adding the other
700 or so CPAN modules
to the list? Even without any of the other data?
Gabor
On Fri, Jun 6, 2008 at 2:45 PM, Gabor Szabo <szabgab@gmail.com> wrote:
> Hi Martín and all the rest,
>
> On Fri, Jun 6, 2008 at 1:40 PM, Martín Ferrari <martin.ferrari@gmail.com> wrote:
>> 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!
>
> Yes, he is always nagging us :-)
>
>> 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?
>
> debian_pkg could be already useful but then we'll have to guess CPAN_dist.
> Maybe it is better if you do it and then slowly update the info on
> each such module
> so you can remove this index file.
>
> We currently don't get the debian version, maybe you should add that always.
>
> All the rest is optional.
> I think the best would be is to leave any field you don't know empty ("").
> That way we can differentiate between 0 bugs and "I don't know". We can then
> figure out some way to indicate that on CPANTS.
>
>
>>
>>> 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.
>
> I thin the for modules that are new the CPAN_ver should be empty and
> as the status
> field will say "NEW" we know not to expect any number there.
>
> Adding the currently worked on CPAN_version could also help getting a
> quick view.
> then a module author will know things will change soon.
>
>>> 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.
>
> Yeah, it a pure CPANTS issue.
>
>>> 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.
>
> So maybe you start creating such a "database" and then you can start
> supplying the info. I'd include
> Module-Name, CPAN_version, URL_to_discussion_where_it_was_rejected,
> 'short explanation'
>
>
>> 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.
>
> Yes, I just noticed dsfg. It is sometimes in the name of the debian package
>
> "libunicode-map8-perl-dfsg", "Unicode-Map8", "0.12", "0", "0"
>
> sometimes in the version number with a ~
>
> "libdata-stag-perl", "Data-Stag", "0.10~dfsg", "0", "3"
>
> and sometimes in the version number with a .
>
> "libdigest-md4-perl", "Digest-MD4", "1.5.dfsg", "0", "0"
>
> Not realy good for us.
>
> It would be the best if you could provide a field with some indication
> (and then again a way to link somewhere where, the CPAN author
> can get the information he needs)
> But I a not sure what really can be done.
> Actually I think I know. There could be a field in the file indicating
> "the opinion of Debian packagers" This could indicate either any kind of
> manual intervention you were forced to do such as removing a file
> or the or the fact we discussed above that you cannot redistribute
> because of some reason.
>
> CPANTS then can have a metric something like "has_bad_karma_in_debian"
> that will be received only if this field is empty.
> The "easily_repackageable_by_debian" would probably also depend on this.
>
>
> thank you very much for your work!
>
> Gabor
>
> --
> Gabor Szabo http://szabgab.com/blog.html
> Perl Training in Israel http://www.pti.co.il/
> Test Automation Tips http://szabgab.com/test_automation_tips.html
>
Reply to: