FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 09-08-2008, 06:35 PM
"Eugene V. Lyubimkin"
 
Default Proposal: user-visible list of divergences from upstream

Sune Vuorela wrote:
> On 2008-09-08, Eugene V. Lyubimkin <jackyf.devel@gmail.com> wrote:
>> My proposal is make the new file named, for example, debian/divergences, =
[snip]
> I think you are trying to overengineer something.
> I really prefer the documentation of debian patches in the patch itself.
>
> http://patch-tracking.debian.net/patch/series/view/kde4libs/4:4.1.1-1/16_debian_menu.diff
>
> for example.
I meant something for users, not for developers... Something official, applicable for most
of packages, that have an official link from p.d.o.

I failed to fetch a human-readable patch info for psi in testing from
patch-tracking.debian.net, for example. Also, it would be better to combine several patch
into one user-visible change in some cases, some patches may not be not "listed" at all;
typos' fixes in documentation are good, but not too serious changes to end users, for example.

--
Eugene V. Lyubimkin aka JackYF, Ukrainian C++ developer.
 
Old 09-09-2008, 12:15 AM
Ben Finney
 
Default Proposal: user-visible list of divergences from upstream

"Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:

> Many of Debian packages have a patches that fixes some important
> bugs which have not accepted by upstream for some reasons, some of
> them also contains improvements, Debian-specific or not.
[…]

> But how can users know about this changes in Debian packages?

By the existing README.Debian and NEWS.Debian conventions (for
persistent and version-sensitive changes, respectively).

--
“There is no reason anyone would want a computer in their |
` home.” —Ken Olson, president, chairman and founder of Digital |
_o__) Equipment Corp., 1977 |
Ben Finney


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 06:34 AM
Reinhard Tartler
 
Default Proposal: user-visible list of divergences from upstream

"Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:

> I failed to fetch a human-readable patch info for psi in testing from
> patch-tracking.debian.net, for example.

Okay, take another example then:
http://patch-tracking.debian.net/package/ffmpeg-debian

When looking at the individual patches, you see a pretty precise comment
at the top of each patch why this patch was introduced with references
to the discussions that lead to creation of that patch.

> Also, it would be better to combine several patch into one
> user-visible change in some cases, some patches may not be not
> "listed" at all; typos' fixes in documentation are good, but not too
> serious changes to end users, for example.

I think it is rather hard to draw a line here, because it very much
depends on the POV of the user. End-users are likely not interested in
the source of a program, they want to use it. (Prospective) Maintainers
and upstreams of the package are interested in seeing all patches
anyways. What kind of users would be interested only in "end-user
visible" changes and is it worth the efford of the maintainer to decide
on this?

BTH, I think the maintainer's time is way better spend with
documententing their patches properly.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 07:29 AM
Matthew Johnson
 
Default Proposal: user-visible list of divergences from upstream

On Tue Sep 09 08:34, Reinhard Tartler wrote:
> BTH, I think the maintainer's time is way better spend with
> documententing their patches properly.
>
I concur. patch-tracking.debian.net is the way forward. Integrating it
with as many other services as possible is, of course, always good

Matt
--
Matthew Johnson


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-09-2008, 09:24 AM
Stefano Zacchiroli
 
Default Proposal: user-visible list of divergences from upstream

On Tue, Sep 09, 2008 at 08:29:00AM +0100, Matthew Johnson wrote:
> I concur. patch-tracking.debian.net is the way forward. Integrating it
> with as many other services as possible is, of course, always good

See #497410 and #498313.

Cheers.

--
Stefano Zacchiroli -*- PhD in Computer Science PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
I'm still an SGML person,this newfangled / All one has to do is hit the
XML stuff is so ... simplistic -- Manoj / right keys at the right time
 
Old 09-09-2008, 11:19 AM
"Eugene V. Lyubimkin"
 
Default Proposal: user-visible list of divergences from upstream

Ben Finney wrote:
> "Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
>
>> Many of Debian packages have a patches that fixes some important
>> bugs which have not accepted by upstream for some reasons, some of
>> them also contains improvements, Debian-specific or not.
> […]
>
>> But how can users know about this changes in Debian packages?
>
> By the existing README.Debian and NEWS.Debian conventions (for
> persistent and version-sensitive changes, respectively).
>
Have non-Debian users access to this files? Have Debian users access to
these files when packages are not installed on system? And when changes
are not persistent (for example, important backported fix for stable
release)?

--
Eugene V. Lyubimkin aka JackYF
 
Old 09-09-2008, 11:33 AM
"Eugene V. Lyubimkin"
 
Default Proposal: user-visible list of divergences from upstream

Reinhard Tartler wrote:
> "Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
>
>> I failed to fetch a human-readable patch info for psi in testing from
>> patch-tracking.debian.net, for example.
>
> Okay, take another example then:
> http://patch-tracking.debian.net/package/ffmpeg-debian
Well, how can users go this site? Is it described in debian policy,
devreference, some user docs?

>> Also, it would be better to combine several patch into one
>> user-visible change in some cases, some patches may not be not
>> "listed" at all; typos' fixes in documentation are good, but not too
>> serious changes to end users, for example.
>
> I think it is rather hard to draw a line here, because it very much
> depends on the POV of the user. End-users are likely not interested in
> the source of a program, they want to use it. (Prospective) Maintainers
> and upstreams of the package are interested in seeing all patches
> anyways. What kind of users would be interested only in "end-user
> visible" changes and is it worth the efford of the maintainer to decide
> on this?
(suppose) I'm a system administrator. I have received new production
mail server. My only choice is a stable well-maintained distribution.
Last release for RedHat contains exim 1.5.19, and Debian version is
1.5.18. I know about recently found security bug in 1.5.18. What
distribution I will choose without official acknowledge that Debian's
source for 1.5.18 already have a backported fix for bug?

Well, for security bugs Debian have DSAs. But for other non-security
fixes and improvements came to stable release?

Many users don't except at all that Debian patches upstream when needed.

--
Eugene V. Lyubimkin aka JackYF
 
Old 09-09-2008, 11:36 AM
Neil Williams
 
Default Proposal: user-visible list of divergences from upstream

On Tue, 2008-09-09 at 14:33 +0300, Eugene V. Lyubimkin wrote:
> Reinhard Tartler wrote:
> > "Eugene V. Lyubimkin" <jackyf.devel@gmail.com> writes:
> >
> >> I failed to fetch a human-readable patch info for psi in testing from
> >> patch-tracking.debian.net, for example.
> >
> > Okay, take another example then:
> > http://patch-tracking.debian.net/package/ffmpeg-debian
> Well, how can users go this site? Is it described in debian policy,
> devreference, some user docs?

It could be linked from the PTS maybe - i.e. package specific - and then
mentioned in the Debian Developer Reference or linked from
http://www.uk.debian.org/devel/ under Miscellaneous. In most cases,
upstream teams should be able to get the majority of the data needed
from the PTS using http://packages.qa.debian.org/$package and then the
BTS.

> (suppose) I'm a system administrator. I have received new production
> mail server. My only choice is a stable well-maintained distribution.
> Last release for RedHat contains exim 1.5.19, and Debian version is
> 1.5.18. I know about recently found security bug in 1.5.18. What
> distribution I will choose without official acknowledge that Debian's
> source for 1.5.18 already have a backported fix for bug?

> Well, for security bugs Debian have DSAs. But for other non-security
> fixes and improvements came to stable release?

BTS and online changelogs linked from the PTS ?


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 
Old 09-09-2008, 11:57 AM
"Eugene V. Lyubimkin"
 
Default Proposal: user-visible list of divergences from upstream

Neil Williams wrote:
> On Tue, 2008-09-09 at 14:33 +0300, Eugene V. Lyubimkin wrote:
>> Reinhard Tartler wrote:
[snip]
>>> http://patch-tracking.debian.net/package/ffmpeg-debian
>> Well, how can users go this site? Is it described in debian policy,
>> devreference, some user docs?
>
> It could be linked from the PTS maybe - i.e. package specific - and then
> mentioned in the Debian Developer Reference or linked from
> http://www.uk.debian.org/devel/ under Miscellaneous. In most cases,
> upstream teams should be able to get the majority of the data needed
> from the PTS using http://packages.qa.debian.org/$package and then the
> BTS.
Yes, this would be good anyway.

>> (suppose) I'm a system administrator. I have received new production
>> mail server. My only choice is a stable well-maintained distribution.
>> Last release for RedHat contains exim 1.5.19, and Debian version is
>> 1.5.18. I know about recently found security bug in 1.5.18. What
>> distribution I will choose without official acknowledge that Debian's
>> source for 1.5.18 already have a backported fix for bug?
>
>> Well, for security bugs Debian have DSAs. But for other non-security
>> fixes and improvements came to stable release?
>
> BTS and online changelogs linked from the PTS ?
For upstream, for Debian people - enough. My proposal is to make
user-oriented list. Long changelog entries with some inner packaging
info and other stuff and viewing dozen of patches (even with good
comments) imho, is not what user have to do to answer on the simple
questions "Have Debian version of package foo, version x.y.z the fix for
A?" and "Have Debian version of package foo, version x.y.z the feature B?".

--
Eugene V. Lyubimkin aka JackYF
 
Old 09-09-2008, 12:02 PM
Neil Williams
 
Default Proposal: user-visible list of divergences from upstream

On Tue, 2008-09-09 at 14:57 +0300, Eugene V. Lyubimkin wrote:
> > BTS and online changelogs linked from the PTS ?
> For upstream, for Debian people - enough. My proposal is to make
> user-oriented list. Long changelog entries with some inner packaging
> info and other stuff and viewing dozen of patches (even with good
> comments) imho, is not what user have to do to answer on the simple
> questions "Have Debian version of package foo, version x.y.z the fix for
> A?" and "Have Debian version of package foo, version x.y.z the feature B?".

Without some form of coordination between all the different bug
trackers, this will never be possible. Security bugs have a
long-standing mechanism for identifying specific issues and therefore
specific fixes across distributions. Other bugs do not - different users
report the same issue in different ways. *IF* the bug is forwarded
upstream, then the upstream bug tracker reference is probably sufficient
but that works best for upstream (who know which patterns to try and
find), not users.

In essence, your request comes down to:

How does a user decide if the fix for issue A in Distro X is equivalent
to the fix for issue B in Distro Y? I see no particular solution to that
other than knowing how each distro records upstream bug references. Even
then, you need upstream to be on-the-ball in marking bugs as duplicates
or merged.

The question is far from simple.

It works for security bugs because a lot of people ensure that it works
- doing it for other issues will require as much, if not more, work.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 04:56 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org