[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

SUMMARY -- (was Bug#27823: proftpd: non-maintainer upload (alpha) diffs)



Joey Hess <joey@kitenet.net> writes:
> One wonders why you don't. Thisporting effort seems to lead to a lot of
> bitter people being involved in it. One wonders why. Anyhow, TTFN.

Well, I think I can see why.  Because porting is a thankless and
gruelling task.  You come head to head with every little packaging
mistake, get bit by the flubs of newbie Debian developers and silly
oversights by developers who should know better, and face the fear,
hostility, and a general lack of understanding by quite a few
(i386-centric) Debian folks.

I think this whole discussion got off on the wrong foot because the
issues got confused.  Let's try to break them out so we can address
them constructively.

ISSUE 1:

Portability or packaging fixes made by porters should propogate into
the "upstream" Debian package.

 Solution: porters must submit bugs for their fixes to the BTS

This is *already* the case, so this is a non-issue, IMHO.  Asking
porters to wait for the upstream maintainer to respond and fix the bug
does *not* scale to the level of packages that porters routinely have
to deal with.  I think that porters should be allowed and encouraged
to do binary-only NMUs + BTS bug filed against package (which some
caveats, see licensing below).

Asking porters to wait is basically like trying to kill the porting
effort, which Mssr. Hess should try to realize.


ISSUE 2:

There are a lot of common errors made by package maintainers, i.e.,
wrong architecture in debian/control, leaving 'debian/files' in the
source package.

 Solution: work with the lintian maintainer and have error conditions
or warnings generated for these cases, if it is not already the case.
Write a section for the packaging manual on dos and don'ts based on
the unique experience of the porters.


ISSUE 3:

Binary-only packages w/o source may break some licenses.  A lot of
this comes down to whether distributing source via the ftp archive,
and patches via the BTS, conform to a given license's requirements.

This issue is being hashed out in <debian-policy>, so I really don't
want to go into it here.  Basically my stand is that assuming that the
patch has been submitted to the BTS, porters should simply be able to
state in the changelog something like "patches for this port available
on the Debian Bug Tracking System <URL:http://www.debian.org/Bugs>".

I think it's important that our ass is covered for GPL and NPL and MPL
packages (or any license w/ the source availability requirement), but
I really don't think ports can succeed if uploading binaries with
minor portability fixes is a major hassle.



Any other issues?  I'm about to go toddle off to the Developer's
Reference and add a section for porters.  I think a clearly documented
practice for porters would be a good thing, i.e., less verbal lore for
porters to have to know, so becoming a porter would be easier, and
more comprehension of the process by x86-centric maintainers.

.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>





Reply to: