RFC: Conditions of early access to unreleased

[Albert Astals Cid]

El Dilluns, 4 de juny de 2012, a les 22:33:55, Will Stephenson va escriure:
> 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.

That's exactly what i was suggesting (if you take my option "b" on the 
publishing side), no?

Albert

> 
> 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
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team