RFC: Conditions of early access to unreleased

Scott Kitterman kde at kitterman.com
Mon Jun 4 04:11:32 UTC 2012


Sorry for breaking threading.  I wasn't subscribed when this was sent, so I 
had to copy/paste from the web archive.

> On Monday, June 04, 2012 00:52:47 Albert Astals Cid wrote:
> > My proposal:
> > 
> > ******************************
> > 
> > The KDE Release Team recognizes the importance of making a source release
> > together with binary packages of various distributions since this greatly
> > increases the impact of a given release.
> > 
> > To this effect we give the privilege of early access to unreleased
> > tarballs
> > to select packagers of distributions
> 
> I like to view it as we have specific points-of-contact within the various
> distributions who have agreed to interact directly with us, the KDE
> developers and community in order to deliver the best possible KDE for
> their
> distribution. As such they have early access to unreleased tarballs to give
> early feedback of issues that would impair their ability to package the
> software so that when Release Day rolls around, there are already KDE
> packages available, yaaay!
> 
> Really though, that's where I try to stop thinking of it being a privilege
> for the packagers. You've certainly seen how hard it is to tag together
> dozens and dozens of disparate modules into a working release, I can't
> imagine it is much easier for the packagers to stitch it together on their
> end.
> 
> I agree candidate tarball releases shouldn't be deliberately announced to
> users or pushed directly to distribution channels, but I would not see major
> issue if enterprising users happened to end up with binary packages. After
> all, they can already run "the upcoming release" using build-tool or kdesrc-
> build so they really have no more advantage or claim to running it than many
> other users.
> 
> If it is required for a distribution's packaging build system to push
> packages out, I would still rather have that than for them to hold up
> making packages until *we* are ready.
> 
> >  * Report any compilation error you might find as soon as possible to the
> > release team mailing list
> > 
> >  * Report any missing package or unpackaged dependency as soon as possible
> > to the release team mailing list

I agree packagers should do this, but it's been done on the packagers list.  I 
think that should be sufficient.  It shouldn't need to go to two lists.

> I agree with this, and AFAIK the packagers have been doing well with this.
> But it's good to have it in writing.
> 
> > Reiterated failure to comply with this guidelines might end up in
> > revocation of your special access to unreleased tarballs.
> 
> I would agree with this, with the proviso that we're talking about a
> guideline more along the lines of "do your best to avoid publicizing the
> new KDE packages" as opposed to "don't let any packages get out at all".
> I'm assuming the packagers generally want this as well instead of having to
> worry about other distros "breaking the street date".

I think putting the focus on don't publicize is the correct one.  Keeping 
things private prior to the final release is important for a number of reasons:

1.  Until release time, the tarballs may change and users shouldn't get the 
incorrect one.
2.  Having everyone publicize availability of source and packages together 
maximizes the impact of the release.
3.  A competition among distributors to be 'first' would invariably lead to 
more freeze breaks and undermine the process.
4.  Having more time to get ready results in higher quality packages.  This is 
good for both KDE and various distributions.

Note that I don't list 'KDE developer doesn't get bugs before the release', 
because they will.  When distributions are testing their packages, they will 
find bugs and report them.  This should be treated as a good thing.

I'm not aware of any distributions doing anything with leaking early packages 
that affects any of the above points, so I think we are in pretty good shape as 
it is.

> > So it turns I'm undecided and don't know if we should un-tighthen the
> > first
> > point to something like
> > 
> >  * Do not make the packages available to your users (in stable or
> > automatically suggested updates to stable versions) before the official
> > tarballs are announced
> 
> I like this much better.

If this were the rule, we (in Kubuntu) could have official packages for our 
development release out significantly closer to release than we do as we 
currently have to recompile everything after the packages are public to get 
into the official archive.

Scott K


More information about the release-team mailing list