info on debian packaging and installer

[Vinoth vijaybabu]

Hi,
I am vinoth, and i am trying do a project called packaging and installer,
and i want create my own debian packaging and installer. Can you help to do
this.
-- 
V.Vinoth Vijaybabu

Re: On syncing freeze dates with other distributions

[Philipp Kern]

On 2009-08-04, Pierre Habouzit  wrote:
> [1] As I'm french, openSuse isn't very relevant here, I bet it's
> different on the other side of the Rhine.

Somewhat.  But it looks to me as Ubuntu having the biggest user share
at the "other" side of the Rhine, to be honest.  I rarely see Fedoras.
Maybe my sample set is biased, though.

Kind regards,
Philipp Kern


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Testing cd

[Simon Paillard]

Hi Sebastian,

debian-project is about discusssing non-technical issues in the
project.

On Tue, Aug 04, 2009 at 12:56:18PM +0200, Sebastian Dudek wrote:
> http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/
> 
> Where is first CD ?

Indeed, 0 file size for
http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/debian-testing-i386-CD-1.iso

debian-cd is the right list for such report.

Thanks for your report.


-- 
Simon Paillard


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Pierre Habouzit]

On Tue, Aug 04, 2009 at 10:29:11AM +0100, Steve Langasek wrote:
> I'm sorry that you have a negative impression of Ubuntu's relationship
> with Debian, but there's plenty of data available that contradicts
> your conclusion (including BTS reports that have been posted to this
> very thread).

The problem is there is also plenty of data, like for example the recent
#539950 (on a package never uploaded to Debian) which is looking a _lot_
like LP#408901. In this bug, the Ubuntu developer is (IMHO) trying to
make the Debian one find, fix and patch the bug for him.

The problem is (as a DD) that I would expect Ubuntu to collaborate the
most on the harder core packages, meaning the toolchain, the kernel,
X... Alas, it happens more coincidentally than on a regular basis, and
that saddens me.

I'm not saying there aren't any working cases of cooperation, and I
welcome them. But there are way too many example of bad (or rather
inexistant) cooperation, or even dirty tricks like #539950, which
undermines the former tries a lot.


-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: Debian decides to adopt time-based release freezes

[Aurelien Jarno]

On Tue, Aug 04, 2009 at 09:28:18PM +0200, Aurelien Jarno wrote:
> On Mon, Aug 03, 2009 at 09:15:03PM +0200, Cyril Brulebois wrote:
> > Bernd Zeimetz  (03/08/2009):
> > > Ack ack ack. I even have the impression that the Canonical employees
> > > want to ensure that Debian gets important things much much later than
> > > Ubuntu.
> > 
> > Obviously false, see how (e)glibc maintainers are pushed by Ubuntu
> > people to get the next release ready, ignoring their own bugs?
> > 
> 
> And for the ones they can't ignore, forwarding them directly in the
> Debian BTS, even if they correspond to a version that has never been
> uploaded to the Debian archive.
> 

And to the upstream BTS, mentioning both Ubuntu and Debian bugs.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Pierre Habouzit]

On Tue, Aug 04, 2009 at 08:09:54PM +0200, Bernd Zeimetz wrote:
> Manoj Srivastava wrote:
> 
> > I also think that we should be looking at when we freeze not
> >  merely at when a derived distro freezes, but when major system
> >  components release, and when top level sister distributions freeze
> >  (we'll get far more benefit for Debian users were we to sync up with
> >  fedora/rhel; and have more clout with upstream, especially if Ubuntu
> >  sync's up with Debian/red hat as well).
> 
> Ack. It makes *mucH* more sense for use to keep in sync with fedora/rhel than
> with Ubuntu. Especially Fedora tries out the very latest funky stuff, it is
> often really worth the work to have a look what they're doing. At the end this
> will help Ubuntu, too - if they manage to change their freeze time to an
> appropriate date similar to the one of Debian.

It depends, and I'm expressing my own opinion, not any kind of release
team one. If we target big milestones of server stuff, then yeah, we
probably want to follow RHEL.  For the desktop, I'm less sure. When I
look around me, I see lots of Ubuntus, some Fedoras and Debians, and
some Arch's[1].


I'm not saying that Ubuntu is better than Fedora or anything similar,
but when it comes to desktop (KDE, GNOME, Firefox, OOo, ...), Ubuntu
isn't less prominent than Feodra/RH is (if you count the user base).
Unlike Fedora/RH though, we have some kinds of (sometimes awkward, but
still existing) ties, that makes such a sync possible. OTOH I see no-one
having started any kind of discussion with red-hat or the fedora
community to even _think_ of such a sync with them.

In France we say "better is the ennemy of good[2]". Try to loosely sync
our freeze dates with Ubuntu is something we can rather easily do, and
that basically cost us nothing.  Even supposing that syncing with
RH/Fedora is better, but I don't see any kind of concrete opportunity
right now, which makes the discussion moot for now.


[1] As I'm french, openSuse isn't very relevant here, I bet it's
different on the other side of the Rhine.

[2] le "mieux" est l'ennemi du "bien"
-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: On syncing freeze dates with other distributions

[Pierre Habouzit]

On Tue, Aug 04, 2009 at 02:54:26PM -0500, Manoj Srivastava wrote:
> On Tue, Aug 04 2009, Anthony Towns wrote:
> 
> > On Tue, Aug 04, 2009 at 11:55:04AM -0500, Manoj Srivastava wrote:
> >> On Mon, Aug 03 2009, Russ Allbery wrote:
> >> > Amen.  I think two years is a little too long and 18 months would be much
> >> > better.
> >> We never actually have managed the 18 month release, have we? We
> >>  freeze approximatly 18 months after the last release, and then release
> >>  about 2 years or so after the last release.
> >
> > By my count:
> >
> > Etch froze after 18 months, and released after 22 months.
> > Lenny froze after 15 months, and released after 22 months.
> 
> So we have done the last two releases in roughly two year
>  intervals, and the freezes roughly two years apart, which is some
>  indication that we can sustain the 24 month cycle, more or less.

Yes.
-- 
Intersec 
Pierre Habouzit 
Tél : +33 (0)1 5570 3346
Mob : +33 (0)6 1636 8131
Fax : +33 (0)1 5570 3332
37 Rue Pierre Lhomme
92400 Courbevoie


signature.asc
Description: Digital signature

Re: On syncing freeze dates with other distributions

[Manoj Srivastava]

On Tue, Aug 04 2009, Anthony Towns wrote:

> On Tue, Aug 04, 2009 at 11:55:04AM -0500, Manoj Srivastava wrote:
>> On Mon, Aug 03 2009, Russ Allbery wrote:
>> > Amen.  I think two years is a little too long and 18 months would be much
>> > better.
>> We never actually have managed the 18 month release, have we? We
>>  freeze approximatly 18 months after the last release, and then release
>>  about 2 years or so after the last release.
>
> By my count:
>
> Etch froze after 18 months, and released after 22 months.
> Lenny froze after 15 months, and released after 22 months.

So we have done the last two releases in roughly two year
 intervals, and the freezes roughly two years apart, which is some
 indication that we can sustain the 24 month cycle, more or less.

> Squeeze freeze is currently planned for 10 months (Dec '09), with
> release perhaps at around 15 months (May '10).

Which seems a bit short for what I wanted to have in the
 release, as I have indicated in other mails.

>
>>  I also think that we should be looking at when we freeze not
>>  merely at when a derived distro freezes, but when major system
>>  components release, and when top level sister distributions freeze
>>  (we'll get far more benefit for Debian users were we to sync up with
>>  fedora/rhel; and have more clout with upstream, especially if Ubuntu
>>  sync's up with Debian/red hat as well).
>
> AIUI, Mark's aim was to get all distros to sync up, not just Debian
> and Ubuntu:
>
> ] There's one thing that could convince me to change the date of the
> ] next Ubuntu LTS: the opportunity to collaborate with the other, large
> ] distributions on a coordinated major / minor release cycle. If two out of
> ] three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree
> ] in advance on a date to the nearest month, and thereby on a combination
> ] of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions,
> ] and agree to a six-month and 2-3 year long term cycle, then I would
> ] happily realign Ubuntu's short and long-term cycles around that. I
> ] think the benefits of this sort of alignment to users, upstreams and
> ] the distributions themselves would be enormous. I'll write more about
> ] this idea in due course, for now let's just call it my dream of true
> ] free software syncronicity.
>
> -- http://www.markshuttleworth.com/archives/146

I would not be opposed to a general 2 ear cycle for most major
 Linux distributions and components; but I think it is perhaps premature
 to shorten the current cycle to freeze in 4 months or so from now in
 advance of indications that we are converging to a common schedule, or
 that any of the underlying agreements mentions above have been arrived
 at.

Based on our last two releases, the natural time frame for
 freeze would be next May/June, looking for a December 2010 release,
 giving us plenty of time to talk to other parties and adjust the
 release for Squeeze + 1 as needed.

manoj
-- 
But the supreme blight, ignorance, is the blight of blights. Destroying
this blight, be free of blights, bhikkhus. 243
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Manoj Srivastava]

On Tue, Aug 04 2009, Anthony Towns wrote:


> I'm a little bothered by the lack of release team involvement in
> the discussion, but I wonder if the reason isn't simply that it's
> probably pretty hard for them to pick a way of responding that won't
> be misinterpreted to fit folks predisposition to argue that "Ubuntu
> are thieves!"  or "everything's always decided behind closed doors!" or
> similar.

I am afraid I do not see how participating in the discussion
 will fuel the paranoia of folks that "everything's always decided
 behind closed doors!" part.  They can always point out how any of the
 proposals being bruited will impact actual releases, or help iron out
 impracticalities in suggestions (not every thing need be shot down out
 of hand [yes, yes, I know, that's what I often do])

manoj
-- 
When all else fails, read the instructions.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Aurelien Jarno]

On Mon, Aug 03, 2009 at 09:15:03PM +0200, Cyril Brulebois wrote:
> Bernd Zeimetz  (03/08/2009):
> > Ack ack ack. I even have the impression that the Canonical employees
> > want to ensure that Debian gets important things much much later than
> > Ubuntu.
> 
> Obviously false, see how (e)glibc maintainers are pushed by Ubuntu
> people to get the next release ready, ignoring their own bugs?
> 

And for the ones they can't ignore, forwarding them directly in the
Debian BTS, even if they correspond to a version that has never been
uploaded to the Debian archive.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Testing cd

[Sebastian Dudek]

http://cdimage.debian.org/cdimage/weekly-builds/i386/iso-cd/

Where is first CD ?


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Mark Brown]

On Tue, Aug 04, 2009 at 11:49:09AM -0500, Manoj Srivastava wrote:
> On Tue, Aug 04 2009, Steve Langasek wrote:

> > If you prefer to be automatically notified about all changes in Ubuntu, I
> > believe the PTS gives you an option to do this by subscribing to the
> > 'derivatives' keyword.  For my part, as a Debian maintainer I greatly prefer

...

> Perhaps Ubuntu should correct it's web page, then, in light of
>  the apparent fact that automatic feeding of patches upstream is
>  not in fact reality?

They do have the automated sending of patches in place (that's the PTS
thing above), though it does require enabling by the recipient too.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Bernd Zeimetz]

Manoj Srivastava wrote:

> I also think that we should be looking at when we freeze not
>  merely at when a derived distro freezes, but when major system
>  components release, and when top level sister distributions freeze
>  (we'll get far more benefit for Debian users were we to sync up with
>  fedora/rhel; and have more clout with upstream, especially if Ubuntu
>  sync's up with Debian/red hat as well).

Ack. It makes *mucH* more sense for use to keep in sync with fedora/rhel than
with Ubuntu. Especially Fedora tries out the very latest funky stuff, it is
often really worth the work to have a look what they're doing. At the end this
will help Ubuntu, too - if they manage to change their freeze time to an
appropriate date similar to the one of Debian.

-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Anthony Towns]

On Tue, Aug 04, 2009 at 11:55:04AM -0500, Manoj Srivastava wrote:
> On Mon, Aug 03 2009, Russ Allbery wrote:
> > Amen.  I think two years is a little too long and 18 months would be much
> > better.
> We never actually have managed the 18 month release, have we? We
>  freeze approximatly 18 months after the last release, and then release
>  about 2 years or so after the last release.

By my count:

Etch froze after 18 months, and released after 22 months.
Lenny froze after 15 months, and released after 22 months.

Squeeze freeze is currently planned for 10 months (Dec '09), with release
perhaps at around 15 months (May '10).

>  I also think that we should be looking at when we freeze not
>  merely at when a derived distro freezes, but when major system
>  components release, and when top level sister distributions freeze
>  (we'll get far more benefit for Debian users were we to sync up with
>  fedora/rhel; and have more clout with upstream, especially if Ubuntu
>  sync's up with Debian/red hat as well).

AIUI, Mark's aim was to get all distros to sync up, not just Debian
and Ubuntu:

] There's one thing that could convince me to change the date of the
] next Ubuntu LTS: the opportunity to collaborate with the other, large
] distributions on a coordinated major / minor release cycle. If two out of
] three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree
] in advance on a date to the nearest month, and thereby on a combination
] of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions,
] and agree to a six-month and 2-3 year long term cycle, then I would
] happily realign Ubuntu's short and long-term cycles around that. I
] think the benefits of this sort of alignment to users, upstreams and
] the distributions themselves would be enormous. I'll write more about
] this idea in due course, for now let's just call it my dream of true
] free software syncronicity.

-- http://www.markshuttleworth.com/archives/146

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Anthony Towns]

On Tue, Aug 04, 2009 at 05:44:58PM +0200, Marc Haber wrote:
> On Thu, Jul 30, 2009 at 11:51:35AM +0200, Raphael Hertzog wrote:
> > Also in many cases, Ubuntu and Debian teams can't fully collaborate
> > because they do not target the same upstream version, freezing at the same
> > time should make it possible to achieve this goal.
> I still see that Ubuntu gets more benefit from that decision. Also,
> the release team's stunning silence to questions asked about their
> decisions makes me wonder.

I'm a little bothered by the lack of release team involvement in
the discussion, but I wonder if the reason isn't simply that it's
probably pretty hard for them to pick a way of responding that won't
be misinterpreted to fit folks predisposition to argue that "Ubuntu
are thieves!"  or "everything's always decided behind closed doors!" or
similar.

I don't know of a solution to that, beyond just accepting you'll be
misinterpreted and responding anyway. 

Maybe a stylised debate would work -- ie, pick a couple of people who
can debate civilly, randomly assign positions under consideration, and
let them make the best arguments they can for those positions, then
see what falls out. Basically, just like school debates, though with
more points for substance than rhetoric. I'd find that fascinating to
follow/participate in, personally.

Alternatively, one of the ideas suggested while I was DPL that I didn't
end up getting a chance to try was having regular "ask the DPL" sessions,
where anyone can mail in questions, then every couple of weeks the DPL
selects a few of them and gives answers. Kind of along the lines of Google
Moderator, perhaps. Maybe something like that could be intriguing, anyway.

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Manoj Srivastava]

On Tue, Aug 04 2009, Steve Langasek wrote:

> On Tue, Aug 04, 2009 at 08:57:50AM +0200, Patrick Schoenfeld wrote:
>> Of course it would be nicer if patches were reported automatically to us.
>
> This is by no means a universally held view within Debian.  The current
> approach of only pushing patches to Debian maintainers as manual bug
> reports is a result of public discussion several years ago on debian-devel
> (or debian-project), in which a number of developers objected to the idea of
> receiving automatic mails every time Ubuntu made a change on the grounds
> that this would generate lots of unwelcome noise.
>
> If you prefer to be automatically notified about all changes in Ubuntu, I
> believe the PTS gives you an option to do this by subscribing to the
> 'derivatives' keyword.  For my part, as a Debian maintainer I greatly prefer
> receiving bug reports with Ubuntu patches because I find the signal-to-noise
> is much better when you have a person to talk to instead of trying to
> extract meaning from a changelog alone.

Perhaps Ubuntu should correct it's web page, then, in light of
 the apparent fact that automatic feeding of patches upstream is
 not in fact reality?

manoj
-- 
It is better to wear chains than to believe you are free, and weight
yourself down with invisible chains.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On syncing freeze dates with other distributions

[Manoj Srivastava]

On Mon, Aug 03 2009, Russ Allbery wrote:

> Michael Banck  writes:
>
>> The other concern I have is lengthening our release cycle to 2 years - I
>> think this is quite a bit too long, I am very happy with the current
>> (rather informel) 1,5 years which is just between the 6-month release
>> cycle of the Fedora, OpenSuSE and Ubuntu community distributions and the
>> RHEL, SLES, LTS enterprise distributions.
>
> Amen.  I think two years is a little too long and 18 months would be much
> better.

We never actually have managed the 18 month release, have we? We
 freeze approximatly 18 months after the last release, and then release
 about 2 years or so after the last release.

So, in steady state, freezing/releasing roughly two years apart
 will be close to what we do, no?

> I don't think Debian should make pledges external to the project about
> our release cycle at this point, at least not until we've done the
> same freeze at least twice on the same schedule and have proven
> internally that we can do it consistently.

I also think that we should be looking at when we freeze not
 merely at when a derived distro freezes, but when major system
 components release, and when top level sister distributions freeze
 (we'll get far more benefit for Debian users were we to sync up with
 fedora/rhel; and have more clout with upstream, especially if Ubuntu
 sync's up with Debian/red hat as well).

manoj
-- 
Money is better than poverty, if only for financial reasons.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Marc Haber]

On Thu, Jul 30, 2009 at 11:51:35AM +0200, Raphael Hertzog wrote:
> On Thu, 30 Jul 2009, Marc Haber wrote:
> > On Thu, Jul 30, 2009 at 10:37:46AM +0200, Raphael Hertzog wrote:
> > > What we're speaking of is synergy between both distributions. You know the
> > > it's the principle behind “the combination of both is worth more that the
> > > sum of individual parts”.
> > 
> > What kind of synergy could Debian get from Ubuntu which it couldn't
> > get in the past? I surely haven't seen any in the past.
> 
> As you might have noticed, Ubuntu is used by lots of people and 
> they start having some influence on upstream projects. Those projects do
> some effort to ensure that Ubuntu has a good version of their software
> (sometimes by using a version that does not come from Debian sid).
> 
> If Ubuntu and Debian used the same version, the incentive would be even
> bigger to publish a really good version because it's going to be used
> very widely in the next 3 years.
> 
> Also in many cases, Ubuntu and Debian teams can't fully collaborate
> because they do not target the same upstream version, freezing at the same
> time should make it possible to achieve this goal.

I still see that Ubuntu gets more benefit from that decision. Also,
the release team's stunning silence to questions asked about their
decisions makes me wonder.

> > > We'll keep our user base
> > 
> > That's what I doubt. Ubuntu LTS will be better than Debian stable in
> > all aspects, why should anybody continue using Debian stable?
> 
> Why are you using Debian and not Ubuntu?

Because I'm a dinosaur who doesn't like changing things.

> I'm also quite convinced that by doing better communication/marketing
> that explains what we are, we can continue to attract new users and new
> developers.

We have always sucked at communicating. The timed freeze issue is a
good example for that.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Michael Banck]

On Tue, Aug 04, 2009 at 08:04:12AM +0200, Giacomo A. Catenazzi wrote:
> Yes, but OTOH we strongly support copyleft softwares versus the BSD-
> like softwares, because we expect to have back the works and
> because we expect to behave as a big community.

No we don't.


Michael


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Marc Haber]

On Tue, Aug 04, 2009 at 11:17:01AM +0100, Steve Langasek wrote:
> On Tue, Aug 04, 2009 at 08:57:50AM +0200, Patrick Schoenfeld wrote:
> > Of course it would be nicer if patches were reported automatically to us.
> 
> This is by no means a universally held view within Debian.  The current
> approach of only pushing patches to Debian maintainers as manual bug
> reports is a result of public discussion several years ago on debian-devel
> (or debian-project), in which a number of developers objected to the idea of
> receiving automatic mails every time Ubuntu made a change on the grounds
> that this would generate lots of unwelcome noise.

If I recall correctly, the consensus of this old discussion was that
Debian would want Debian-relevant patches in the BTS while Ubuntu
could happily keep their "fixes" such as disabling the parts of test
suites that failed during the Ubuntu build for themselves.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Piotr Ożarowski]

[Sandro Tosi, 2009-08-03]
> Hey, but we give back (patches, improvements, bug reports) to upstreams :)

IIRC, I never used a patch from Ubuntu (let's be honest: their patches
are usually not that good, at least the ones for packages in universe,
see latest python2.6 transition for examples), but if you'll encourage
them, they give something else - much more important IMHO - maintainers
(manpower ;). I hang on #ubuntu-motu channel (with "python" highlighted
by Irssi) and from time to time, I respond to Python related problems
and if one is happy with my help, I add "you'll get more comments/help
if you'll join one of our teams and maintain your package in Ubuntu via
Debian" (i.e. I steal maintainers ;) and this way people like Scott,
Emilio, Luca or Siegfried (+many others) maintain dozens of packages
in Debian and know much more about packaging Python related stuff than
many other DDs.

My point is:
* patches and bug reports are not the only way to contribute back
* it is also up to us if we'll get some help or not (if you'll
  just complain, nobody will want to work with you)
-- 
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Re-thinking Debian membership - take #1: inactivity - status update

[Stefano Zacchiroli]

On Mon, Aug 03, 2009 at 04:21:37PM +0200, Sandro Tosi wrote:
> >> - what to do about the current (yet unanswered) queries we've
> >> received? should we reply "please wait for  to be approved"?
> >> should we fulfill? when should we stop operations? (I'm personally not
> >> that motivated to work on something that's dying.)
> > There is no reason at all to change processing.
> While I can see it can be still has its space for non-DDs (but it's
> *much* more difficult our work for them) I don't see if it's still
> worth have it once this proposal is implemented.

Just my 0.02€ on this. I think it is still totally worth (which is of
course a totally differ topic than saying that the current MIA team
has enough manpower for that). Lucas Nussbaum (Cc-ed) showed me some
interesting numbers about how many packages in the Debian archive are
currently maintained by non-DD-maintainers. They are quite a lot in
fact, and not only due to DM.

With that slices of the archive increasing, the reasons which brought
us to have MIA for DDs apply more and more to non-DD-maintainers.

> > You seem to misunderstand the proposal AFAICS. The MIA Team would
> > still be operative for non DDs in general and for DDs in a
> > proactive way (aka during the inactivity period).
> 
> but what is the point in proactively checks DDs if after  decided by DAM> they are removed from the project? we can simply
> wait for that time to pass, or am I missing something?

I agree with you on this: I don't see the point in investing MIA
energy in DDs when this proposal will be implemented.

Still, the topic of packages de facto unmaintained by otherwise active
DDs (e.g. people that vote but don't fix/respond to RC bugs) remains a
big one. However, it is a totally orthogonal problem to MIA already.

> also note that non-DDs checks are far more difficult to be performed
> than for DDs, where we have plenty of data sources to check if
> they're active or not. Keeping the infrastructure only of this
> "hard"/rare/less-important (for the project) cases seems overkill to
> me.

See above: I don't think it is in any way less important and is likely
to become more and more important in the future.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Re-thinking Debian membership - take #1: inactivity - status update

[Stefano Zacchiroli]

On Mon, Aug 03, 2009 at 04:37:54PM +0200, Sandro Tosi wrote:
> That is the much more time-consuming than checking DDs. for our fellow
> DDs we have several data sources (mls posts, uploads, key usage) to
> track them, while we don't have anything similar for non-DDs. So
> several manual researches are needed (either on lists.d.o, google, etc
> etc).
> 
> So, while removing the "easiest" part (checking DDs) we are left with
> the most difficult and time-consuming part.

Sure, but it seems an advantage nevertheless to me: we de facto ease
remove part of the task. Also, I fail to understand how things were
different with WAT runs. The relations of that with MIA seem identical
to me to the relations of the new proposal to MIA.

> Ok, so there should be a communication of removed DDs, at least on
> -private, so that DDs working on QA at least know it. if you/other
> feel it unappropriate, please suggest some other form of
> communication or ways to handle this. either in this proposal or at
> a later stage.

I consider it totally appropriate. Probably -private would not be
enough though, and also some "private QA" channel would need to be
triggered. How it was for MIA? I presume we can use the same channel.

> > ACK. Again, I don't see MIA "dying" due to this proposal, I only
> > see it re-focusing his work on non-DD maintainers.
> 
> see above: this way our work is reduced in number, to focus on the
> most annoying, difficult, quite frustrating and pointless (non-DDs
> are not part of the project, in a strict sense (don't get me wrong
> here, I know they are valuable contributors, but they can't vote,
> blablabla)).

Understood. This proposal is no solution for that and I don't see an
easy one. Still, given the main utility of MIA has always been to
discover unmaintained *packages* by the main of MIA *developers*, I
feel like we still need that. How to improve it is a, recurrent,
totally different topic.

> But I also have to be honest and affirm that we receive much less
> requests for non-DDs than for DDs.

> > I don't have _the_ answer for that. What I can do, if you are
> > interested, is to hand over the list of potentially disabled DDs
> > to pinpoint your MIA queries at them and avoid/focus MIA
> > activities elsewhere.
> 
> Of course it would be welcome: I'll cross check the current "TODO"
> list marking as 'pending on the proposal to be implemented'
> accordingly.

OK. I'll contact you in private for further development on this side
of the issue.

> > contacted me on IRC. At the end of that
> Yes, I contacted you, and I was quite surprised by this sudden
> proposal. Probably I should have made clear at that time that a
> contact would have been welcome.

My bad then, I could have understood that too. Sorry for the
misunderstanding, I hope things are clear(er) now.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Debian decides to adopt time-based release freezes

[Bernd Zeimetz]

Mark Brown wrote:
> On Mon, Aug 03, 2009 at 04:13:03PM +0200, Bernd Zeimetz wrote:
> 
>> I rarely hear anything positive from Ubuntu, except that more and more people
>> who are active in Ubuntu realized that it is much better to do things in 
>> Debian
>> directly.
> 
> IME the quality of interaction from Ubuntu is very variable and depends
> strongly on who in Ubuntu looks at the package.  For packages which are
> just getting janatorial cleanup work as a result of having been pulled
> into universe things tend to be pretty poor, both in terms of the code
> and in terms of pushing things back into Debian.  This often creates a
> very bad impression.  For other things, usually things that are more
> important within Ubuntu, things tend to be a lot better.

That's true of course, unfortunately there are many more packages which were
pulled into universe than packages with an actual maintainer.


-- 
 Bernd Zeimetz Debian GNU/Linux Developer
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian redesign

[Harald Braumann]

Hi,

(please don't CC me)

On Tue, 4 Aug 2009 00:06:46 +0100
Roger Leigh  wrote:

> On Mon, Aug 03, 2009 at 10:28:33PM +0200, Harald Braumann wrote:
> > I must say, I like the current swirl and I would miss it. But then
> > I'm maybe just conservative. I never understood the sense of
> > re-branding, re-naming, re-designing everything just for the sake
> > of it.
> 
> I don't know, while the swirl is familiar and everything, there's
> nothing in it that really jumps out at me and says that's a really
> great logo that captures what Debian is in the same sense that
> (off the top of my head) the VMware (in particular) or
> RedHat/SuSE/FreeBSD logos do.  

Let's see:
VMware: I had to go to their web site to be reminded of their logo. And
if I would see it without the vmware wording, I probably wouldn't
recognise it.
RedHat: well that's easy. But the name Debian doesn't mean anything. If
you want smth. similar, you'd have to use pictures of Debra and Ian ;)
SuSE: how does a chameleon capture what SuSE is?
FreeBSD: Granted, Beastie is cool. But the new abstract logo is also
only recognisable, if you know where it came from.

The conclusion is: most logos are abstractions, and while they might
have had an original meaning, this meaning is usually lost if you don't
know the history. They become a symbol that stands for the brand
itself. Compare e.g. the Adidas stripes: they don't have any meaning of
their own, but everyone knows, it's Adidas. So I wouldn't try too hard
to create a logo that has some meaning of its own.

Somehow you have to implant the connection logo-brand into the
peoples' brains. And as Debian probably doesn't have the advertisement
budget of Adidas, this process is much slower. Thus it's important to
keep the logo for a long time. If you change it, you have to start all
over again

> There are a lot of similar swirl logos
> around which look awfully similar (some even having strangely similar
> spiky bits; the last one I saw was on a bottle of drinking water but
> in silver rather than red).

True. If you put the Debian swirl anywhere, no one would know it's
Debian. But if you put it in some IT-context, it's quite unique.

> I really liked the personality of the "Debian chicken", though it
> wouldn't have hurt to redraw it nicely.  Maybe a bit Linux-specific
> though.
> 
> I also really liked the black and white GNU + penguin on the old
> Apache default index page with the proud and mighty Gnu looking down
> gravely towards the small upstart Penguin!

I don't know if its just me, but IMO animals as logos always look a bit
stupid and childish.

Cheers,
harry


signature.asc
Description: PGP signature

Re: Debian decides to adopt time-based release freezes

[Patrick Schoenfeld]

On Tue, Aug 04, 2009 at 11:17:01AM +0100, Steve Langasek wrote:
> On Tue, Aug 04, 2009 at 08:57:50AM +0200, Patrick Schoenfeld wrote:
> > Of course it would be nicer if patches were reported automatically to us.
> 
> This is by no means a universally held view within Debian.  The current
> approach of only pushing patches to Debian maintainers as manual bug
> reports is a result of public discussion several years ago on debian-devel
> (or debian-project), in which a number of developers objected to the idea of
> receiving automatic mails every time Ubuntu made a change on the grounds
> that this would generate lots of unwelcome noise.
> 
> If you prefer to be automatically notified about all changes in Ubuntu, I
> believe the PTS gives you an option to do this by subscribing to the
> 'derivatives' keyword.  For my part, as a Debian maintainer I greatly prefer
> receiving bug reports with Ubuntu patches because I find the signal-to-noise
> is much better when you have a person to talk to instead of trying to
> extract meaning from a changelog alone.

I think I misexpressed myself here. What I meant is contrary to us
pulling patches manually out of Launchpad or the Ubuntu archive our
other Ubuntu sources. It should be called semi-automatically or
something like that.

Regards,
Patrick


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Steve Langasek]

On Tue, Aug 04, 2009 at 08:57:50AM +0200, Patrick Schoenfeld wrote:
> Of course it would be nicer if patches were reported automatically to us.

This is by no means a universally held view within Debian.  The current
approach of only pushing patches to Debian maintainers as manual bug
reports is a result of public discussion several years ago on debian-devel
(or debian-project), in which a number of developers objected to the idea of
receiving automatic mails every time Ubuntu made a change on the grounds
that this would generate lots of unwelcome noise.

If you prefer to be automatically notified about all changes in Ubuntu, I
believe the PTS gives you an option to do this by subscribing to the
'derivatives' keyword.  For my part, as a Debian maintainer I greatly prefer
receiving bug reports with Ubuntu patches because I find the signal-to-noise
is much better when you have a person to talk to instead of trying to
extract meaning from a changelog alone.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Mark Brown]

On Mon, Aug 03, 2009 at 04:13:03PM +0200, Bernd Zeimetz wrote:

> I rarely hear anything positive from Ubuntu, except that more and more people
> who are active in Ubuntu realized that it is much better to do things in 
> Debian
> directly.

IME the quality of interaction from Ubuntu is very variable and depends
strongly on who in Ubuntu looks at the package.  For packages which are
just getting janatorial cleanup work as a result of having been pulled
into universe things tend to be pretty poor, both in terms of the code
and in terms of pushing things back into Debian.  This often creates a
very bad impression.  For other things, usually things that are more
important within Ubuntu, things tend to be a lot better.


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Steve Langasek]

On Mon, Aug 03, 2009 at 04:13:03PM +0200, Bernd Zeimetz wrote:
> > There seems to be an assumption here that Ubuntu would benefit from bugfixes
> > from Debian developers, but that the reverse would not be true.  Is this
> > what you believe?  Does that mean you don't think Ubuntu developers
> > contribute fixes back to Debian today?

> > While never committing to keep any given package in sync with Debian, Ubuntu
> > developers certainly are actively engaged in pushing their changes upstream
> > to Debian.

> Oh, really? Within the last year I looked at about 20-30 bugfixes/changes
> which were made in Ubuntu. Here are some statistics (no, I didn't properly
> count them):

> 3 of them were reported back to Debian (yay!) - and they were really useful.
> About 5-10 changes were utter bullshit, like disabling regression tests 
> instead
> of fixing the real problem when they start failing due to other changes in the
> distribution.
> All the others I had to pull from launchpad...

> Often there were .ubuntu versions introduced, although it would have been
> easy for the person (DD, member of the right teams) to change these things
> in Debian and let it migrate to Ubuntu.

My proposition was that "Ubuntu developers are actively engaged in pushing
their changes upstream to Debian."  It was *not* that all changes made in
Ubuntu are forwarded to the Debian BTS.  That you choose to equate the two,
and furthermore that you complain about the quality of the changes which
were *not* forwarded to Debian (did it not occur to you that the lack of
forwarding of ugly hacks might have been a conscious decision?), tells me
that you are predisposed to dislike Ubuntu and that you found what you
wanted to when looking at Ubuntu changes.

Changes that Ubuntu has not submitted to Debian are not proof that Ubuntu is
not actively engaging with Debian.  Changes that Ubuntu has made that you
disapprove of are not proof that Ubuntu is not actively engaging with
Debian.  Nor is any of this proof that Ubuntu's contributions to Debian are
insignificant.

I'm sorry that you have a negative impression of Ubuntu's relationship with
Debian, but there's plenty of data available that contradicts your
conclusion (including BTS reports that have been posted to this very
thread).  Since you don't appear interested in helping to *improve* Ubuntu's
relationship with Debian, I'm not going to waste my time arguing with you
about it.

> I rarely hear anything positive from Ubuntu, except that more and more people
> who are active in Ubuntu realized that it is much better to do things in 
> Debian
> directly.

Which I'll note you manage to not give Ubuntu credit for here, even though
this is also something that's actively encouraged in the Ubuntu community
when it's appropriate. 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Debian decides to adopt time-based release freezes

[Marc Haber]

On Mon, Aug 03, 2009 at 09:15:03PM +0200, Cyril Brulebois wrote:
> Bernd Zeimetz  (03/08/2009):
> > Ack ack ack. I even have the impression that the Canonical employees
> > want to ensure that Debian gets important things much much later than
> > Ubuntu.
> 
> Obviously false, see how (e)glibc maintainers are pushed by Ubuntu
> people to get the next release ready, ignoring their own bugs?

There are always exceptions to a rule.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org