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 [email protected] mailing list > * Please report any missing package or unpackaged dependency as soon as > possible to the [email protected] 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 > [email protected] > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
