This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <sgran@debian.org> writes:
>
> > Well, the problem is that the procedure that we have is called
> > backports.org, or private repositories. I agree that we also have a
> > lack of an agreed upon maintenance strategy, but I respectfully
> > disagree that we have either a team or an archive at present. I
> > think these types of packages are _not_ security related, or at
> > least not in the sense for which security.d.o has been used in the
> > past.
>
> The problem is not "find an archive"; the problem is not "find a
> team". The problem is "what is the correct maintenance strategy".
> Right now we have none, but at least it is at arms-length.
Right now, we have a disorganized group of people hoping to make
something happen. I agree that this should better resemble a team
actually doing something if we hope to release with this idea in place.
> If you want it closer to Debian, then you need a better maintenance
> strategy than "we get to make arbitrary upgrades".
>
> If you come up with a maintenance strategy that you and the other
> relevant developers are willing to put into place, then presto!
> there's your team. And making the repository at that point is trivia.
> What is lacking is not the repository, and not the team, but the
> concrete policy statement about what maintenance strategy you want.
>
> So far all I hear is "there are no limits on what possibly
> destabilizing changes we will want to make to these packages." In my
> opinion, that's not an acceptible maintenance strategy.
This one time, at band camp, Thomas Bushnell BSG said:
> Stephen Gran <sgran@debian.org> writes:
>
> > Hmm, I rather thought that several people, myself included, had
> > offered to take on the work of doing what we thought was valuable,
> > and you have been trying to push it off on the security team over
> > strenuous objections that it is not their job.
>
> No, you misunderstood my point. I confess that this is largely
> because I was trying to make it in an ineffective manner, so it is my
> own fault that it got confused.
Fair enough - all I was hearing was "talk to the security team". That
was probably obfuscating the rest of your message, at least for me.
> What I'm saying is that it doesn't matter yet whose job it is, because
> the problem isn't "who does the job" but rather "what job should be
> done". Nor, for the same reasons, does it matter whether we have a
> separate archive. We can figure that out only once we know what the
> archive is actually for.
>
> So far, it sounds like the archive is a place to allow certain package
> maintainers to make arbitrary possibly destabilizing changes to
> packages in stable, without giving any indication about, for example,
> that they will backport all changes.
>
> For example, a new set of virus definitions, we are told, may include
> a new library and a new strategy for catching viruses. Makes sense to
> me. But when you add that, are you just going to add in the latest
> upstream version of the virus-catcher? In which case, you are *also*
> going to be adding in new substantive features, like say a new
> command-line syntax, or a new interface to the mail system, or other
> things that are not connected to catching a new category of viruses.
>
> It is *those* changes which are not allowed for security updates, and
> should not be allowed for these packages either.
>
> In other words, are your upgrades going to be "install the latest
> upstream", or are they going to be "fetch the relevant new things from
> upstream and put them in the old thing"? I agree completely that the
> latter is more work, but that is not an excuse for choosing the
> destabilizing strategy.
>
> It is for this reason that I was referring to the security team's
> procedures early on, not because I care *who* does the work, but
> because I care *that* a certain kind of work gets done. All I heard
> was "we want to make arbitrary changes to packages of this kind", and
> that is simply not the only way to keep abreast of new virus-catching
> things.
>
> Can you write a policy which says that the only changes which will be
> made are specific changes known to catch viruses, but *not* the
> addition of new features, new interfaces to other parts of the system,
> and the like?
I am terrible at doing things like drafting policy statements, but I
will take a stab at it.
This archive (as-yet-to-be-named.debian.{org,net}) is intended for
packages that must, because of the nature of the modern internet, change
more rapidly than the standard release policy allows. This archive is
definitely _not_ the security archive, as updates to this archive are
not intended to address possible compromises of the machine running
these packages.
Developers and maintainers with packages in this archive agree to
maintain API compatibility (although not always ABI compatibilty - see
below) with packages that rely on them in the normal stable
distribution. When new upstream developments warrant changes to a
package in this archive, changes should be backported if at all
possible. It is understood that there may be circumstances where a
backport may not be feasible (e.g., ABI change, or major rewrite of a
core element of the software suite), but with these sorts of exceptions
noted, changing the underlying compatibilty is highly discouraged.
Packages that expect to undergo ABI changes during the lifetime
of a stable release must provide a consistent API, either in the
form of compatibility scripts or programs (e.g., spamc or clamdscan)
that interface with the underlying ABI but continue to provide input
and output in the manner expected by programs in stable, or through
continuing to support the older API after upstream has deprecated it.
I see the probability that packages in this class will have libraries
directly in use by other packages (for instance, I see only one package
outside of the ClamAV suite that depends on libclamav1 and none that use
Mail::Spamassassin directly) as fairly low, and careful coordination with
the maintainers of those packages that do will be necessary to make sure
no breakage occurs.
Additionally, any new dependencies, whether in the form of libraries or
other packages, must be available within the current stable release.
If, for instance, spamassassin makes a large ABI change that requires a
new perl module, then one of the members maintaining this archive must
also maintain a stable backport of that perl module in order for those
changes to be accepted.
I think that about covers my concerns, although I am not sure that it
covers yours (Thomas) or others. Please, if you have better or
different ideas, chime in.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sgran@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
Attachment:
pgp5WXmVGtPm9.pgp
Description: PGP signature