RFC: Conditions of early access to unreleased

[Will Stephenson]

On Sunday 03 Jun 2012 22:28:31 Michael Pyne wrote:
> 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 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".
> 
> > 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.

I agree with Michael - the privilege is really minimal, and the days when 
distros were deliberately releasing KDE early to get an advantage are long 
gone, so there's no need to come on all heavy and threaten sanctions to our 
downstreams - it just creates a bad atmosphere where KDE stands to lose most. 

Most distros are offering packaged git snapshots perfectly legitimately 
anyway.  I think these rules are an overreaction to Martin's complaint about 
the beta1 announce and undo, and would write *that* off as an accidental 
consequence of the transition within our release management.

I'd rather send some guidelines to kde-packager@ and new packagers such as:

* Please report any compilation errors you may find as soon as possible to the 
release-team at kde.org mailing list
* Please report any missing package or unpackaged dependency as soon as 
possible to the release-team at kde.org mailing list
* Test the packaged tarballs within your distribution team but please do not 
announce or release them to end users until the published KDE release date, 
because premature widespread bugreports about release showstoppers create 
unnecessary work for developers and bad publicity.

IF "Rebel Distribution" steps up and starts deliberately flouting these, then 
you can revoke their ftp access, but start with a trusting relationship with 
all downstreams.

FWIW the Open Build Service allows packages to be built but not published, and 
additionally allows selected OBS users the right to download unpublished 
packages, eg for testing, using "osc getbinaries".  But this is of little use 
for testing a project of KDE's size - it's a pain in the ass to download all 
the build results of a KDE tarball set, then run createrepo on them, then 
install from that.  For 'openSUSE KDE developer testing' I'd prefer to publish 
them to an unpublicised repository that can be added as an install source for 
testing, then copy the packages back into the official repo before release 
day.  If some nosy non-contributor wants to grab these in advance and start 
spamming BKO then I'd view that as no more serious than someone reporting git 
snapshots under the wrong version number.

Will