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

Re: unauthorized upload of xfree86 4.3.0-1 to unstable



On Thu, Jan 29, 2004 at 06:22:24PM +0100, Andreas Metzler wrote:
> Branden Robinson <branden@debian.org> wrote:
> > On Thu, Jan 29, 2004 at 01:08:19PM +1100, Daniel Stone wrote:
> [...]
> >> I did, however, state that I felt that 4.3.0-1 was by far the superior
> >> base to work from in sid, for a number of reasons (not least that
> >> propagation to sarge would put the XSF in the position of having to
> >> maintain two codebases, not three).
> 
> > Why do you presume to speak for the entire XSF here?  Maintaining more
> > codebases is potentially *good*, not bad.
> 
> Hello,
> Can you elaborate on that?

Sure.

> Simple minded as I am I fail to see the benefits of maintaining 4.1,
> 4.2 and 4.3 at the same time (i.e.  tracking bug-reports, fixing
> serious ones possibly thrice) has, it just looks like more work.

It is more work, but that's not a problem if there are people available
to do it.

I personally regard three lines of development as "musts":

* A branch corresponding to the version of the package in the last
  Debian release MUST be maintained, so that security updates can be
  applied (and important bugfixes can be applied if the Stable Release
  Manager can be persuaded to accept them).
* A branch with as few release-critical bugs as possible (preferably
  zero) MUST be maintained in unstable so that the Release Manager is
  free to exercise his or discretion as to when we should freeze or
  release.  For an infrastructural package like XFree86, this is also
  polite to users who do us the service of tracking testing or unstable,
  and to maintainers whose packages depend on it.
* When applicable, the latest upstream release of the software MUST be
  maintained in a branch and introduced into unstable if it satisfies
  the previous criterion, and maintained in experimental or a
  third-party repo if it does not.

So that's 2--3 branches to maintain at all times, no matter what.

Some people care not a whit for the first two MUSTs, and care only about
the last.  Others appreciate efforts to keep unstable from going too
haywire, and still others appreciate the fact that we trouble ourselves
to apply security updates to the stable release.

If people who are most interested in item 3 have screamed the loudest,
it is in part because I have served their needs least effectively.

Hence the process of migrating Debian's XFree86 package maintenance to a
publicly visible phenomenon.  It is my way of drawing attention to the
endeavor and encouraging participation my others, so that I may delegate
some of these responsibilities.

> > A lot of users are interested in a backport of 4.3.0 to woody;
> > Dagfinn Ilmari Mannsåker volunteered to maintain it, but didn't have
> > time.  Within the past week or so, Norbert Tretkowski and I spoke on
> > IRC, and he'd like to take up that responsibility.
> [...]
> 
> I fail to see how a 4.3.0 backport is connected to keeping on
> maintaining 4.2 for sid. - I actually wanted to snip this paragraph
> but wanted to sidestep a "see the part you did not quote" answer. ;-)

That's simple.  While I don't have the time or inclination to maintain
such a thing myself, if someone else wants to do it, I see no reason not
to work with them as closely as I can.  It will help ensure parity
between the backport and the mainline, get the backporter used to
working collaboratively with the XSF in particular, and help us (the XSF
and the Project in general) identify people who have the skills
necessary to wrangle what is sometimes a difficult package to maintain.

I would like to delegate some or all of the "MUSTS" identified above to
other people, or to small teams, in the near future.

-- 
G. Branden Robinson                |      Intellectual property is neither
Debian GNU/Linux                   |      intellectual nor property.
branden@debian.org                 |      Discuss.
http://people.debian.org/~branden/ |      -- Linda Richman

Attachment: signature.asc
Description: Digital signature


Reply to: