kdebindings can be removed from SVN
Hi, the kdebindings module in SVN trunk still contains three components. Asking about their status on the bindings list, I received the answer, that those are deprecated/unmaintained and can be removed. http://lists.kde.org/?l=kde-bindings&m=130869565121242&w=2 kalyptus/ Deprecated, replaced by smokegen. Seems from KDE 3 times. php/phpqt/ Unmaintained. Seems from KDE 4 times. xparts/ Unmaintained, not used and not compiling anymore for ages. Seems stuck somwhere in 3->4 porting efforts. I therefor propose to move these last three components to tags/unmaintained and replace the whole kdebindings contents by one README file (not one for every component). Who would do such a move, since tags/ is restricted (it is, right?). Regards ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
On Tuesday 21 June 2011 19:33:09 Christoph Cullmann wrote: > On Tuesday 21 June 2011 02:46:13 Frederik Schwarzer wrote: > > Hi, > > > > because of all the trouble the moving migration caused so far, > > As of now, Dirk had to ask before every release, what he should release > > from where. > > I thought it might be a good idea to make things more ... written-down. > > > > http://techbase.kde.org/Projects/MovetoGit/Progress > > > > I hope I got the current status correctly. If not, feel free to comment > > here, make changes directly or hit me on IRC (icwiener). > > > > What I am especially interested in is feedback from you, Dirk, > > on how helpful this might be if properly maintained. > > kate.git should be released still from SVN for kde 4.6. Ah, sorry :/ Ignore me all. I meant from kdelibs/kdebase modules which were already git in KDE 4.6 if the page is correct, sorry for all noise :/ The reason for no tags in kate.git is that it has no former releases, old stuff until 4.6.x is in other modules. Are there no KDE 4.7 tags yet? Greetings Christoph ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
On Tuesday 21 June 2011 02:46:13 Frederik Schwarzer wrote: > Hi, > > because of all the trouble the moving migration caused so far, > As of now, Dirk had to ask before every release, what he should release > from where. > I thought it might be a good idea to make things more ... written-down. > > http://techbase.kde.org/Projects/MovetoGit/Progress > > I hope I got the current status correctly. If not, feel free to comment > here, make changes directly or hit me on IRC (icwiener). > > What I am especially interested in is feedback from you, Dirk, > on how helpful this might be if properly maintained. kate.git should be released still from SVN for kde 4.6. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
On Tuesday 21 June 2011, Maciej Mrozowski wrote:
> On Tuesday 21 of June 2011 02:46:13 Frederik Schwarzer wrote:
> > Hi,
> >
> > because of all the trouble the moving migration caused so far,
> > As of now, Dirk had to ask before every release, what he should release
> > from where.
> > I thought it might be a good idea to make things more ... written-down.
> >
> > http://techbase.kde.org/Projects/MovetoGit/Progress
> >
> > I hope I got the current status correctly. If not, feel free to comment
> > here, make changes directly or hit me on IRC (icwiener).
> >
> > What I am especially interested in is feedback from you, Dirk,
> > on how helpful this might be if properly maintained.
>
> Excellent, thanks!
>
> A small question to release-team here (and repo maintainers), would it be
> doable to have the same branch names for all packages released under "KDE
> SC" umbrella?
Yes, please.
> Currently, while KDE/${major}.${minor} is obviously the most popular one,
> variations exist.
Sounds good IMO.
> I believe it doesn't help from packager point of view wrt
> scripting the process - and certainly makes things a bit more complex from
> distro packager point of view (hunting down all branching/tagging variants
> from all project repos,
> Sure it applies mostly to distros that track code from repositories - not
> just when tarballs are released - which is minority I believe.
>
> "${major}.${minor}" branch names can be also confusing (for newcomers but
> still) in case of apps that provide own versioning as well, for instance
> Okular in 4.6 branch reports itself as Okular 0.12.4, analogy with Marble
> (randomly picked examples here, no strings attached).
>
> Adding 'KDE/' prefix to branch names would without doubt denote that this
> particular branch is to be used for fetching and tagging for KDE SC
> distribution (when certain application is released so probably tagged
> individually as well).
>
> I understand however that consistency on this field and on tag names
> imposes certain "KDE workflow" (to "natively" use KDE/${major}.${minor}
> branch names) on apps that aim to "sell themselves on their own"
Should they maybe be in extragear then ?
Alex
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
[Christoph Cullmann - Dienstag, 21. Juni 2011 19:39:19] > On Tuesday 21 June 2011 19:33:09 Christoph Cullmann wrote: > > On Tuesday 21 June 2011 02:46:13 Frederik Schwarzer wrote: > > > Hi, > > > > > > because of all the trouble the moving migration caused so far, > > > As of now, Dirk had to ask before every release, what he should release > > > from where. > > > I thought it might be a good idea to make things more ... written-down. > > > > > > http://techbase.kde.org/Projects/MovetoGit/Progress > > > > > > I hope I got the current status correctly. If not, feel free to comment > > > here, make changes directly or hit me on IRC (icwiener). > > > > > > What I am especially interested in is feedback from you, Dirk, > > > on how helpful this might be if properly maintained. > > > > kate.git should be released still from SVN for kde 4.6. > Ah, sorry :/ > Ignore me all. I meant from kdelibs/kdebase modules which were already git in > KDE 4.6 if the page is correct, sorry for all noise :/ Ah, right. I will add a comment about the move. Kate was moved from kdelibs and kdesdk to kdebase, right? > The reason for no tags in kate.git is that it has no former releases, old > stuff > until 4.6.x is in other modules. Are there no KDE 4.7 tags yet? That would lead to another question. Many repos lack recent tags. Even two out of the three kdebase repos do not have a v4.6.4. There might be a reason for that but in any way, it's stuff for another thread. :) Regards ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Team BoF at desktop summit
A Tuesday, June 21, 2011, Sebastian Kügler va escriure: > Hi, > > I'd like to organise a BoF at the desktop summit, as I think we have quite > some stuff to talk about, for example: > > - tarball layout > - release process and sustainability > - communication inside the team, and outside of it > - release schedule in the future > - ... > > And more. In order to get a room and timeslot, I'd need a co-host, > basically one of your names to put next to mine, so there's at least > somebody in case I don't make it. > > Whose name can I put down? If noone else volunteers you can write me down. Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to release from where?
On Tuesday 21 of June 2011 02:46:13 Frederik Schwarzer wrote:
> Hi,
>
> because of all the trouble the moving migration caused so far,
> As of now, Dirk had to ask before every release, what he should release
> from where.
> I thought it might be a good idea to make things more ... written-down.
>
> http://techbase.kde.org/Projects/MovetoGit/Progress
>
> I hope I got the current status correctly. If not, feel free to comment
> here, make changes directly or hit me on IRC (icwiener).
>
> What I am especially interested in is feedback from you, Dirk,
> on how helpful this might be if properly maintained.
Excellent, thanks!
A small question to release-team here (and repo maintainers), would it be
doable to have the same branch names for all packages released under "KDE SC"
umbrella?
Currently, while KDE/${major}.${minor} is obviously the most popular one,
variations exist. I believe it doesn't help from packager point of view wrt
scripting the process - and certainly makes things a bit more complex from
distro packager point of view (hunting down all branching/tagging variants
from all project repos,
Sure it applies mostly to distros that track code from repositories - not just
when tarballs are released - which is minority I believe.
"${major}.${minor}" branch names can be also confusing (for newcomers but
still) in case of apps that provide own versioning as well, for instance
Okular in 4.6 branch reports itself as Okular 0.12.4, analogy with Marble
(randomly picked examples here, no strings attached).
Adding 'KDE/' prefix to branch names would without doubt denote that this
particular branch is to be used for fetching and tagging for KDE SC
distribution (when certain application is released so probably tagged
individually as well).
I understand however that consistency on this field and on tag names imposes
certain "KDE workflow" (to "natively" use KDE/${major}.${minor} branch names)
on apps that aim to "sell themselves on their own" or involves more merging
work otherwise (but hey. branches are cheap in git).
Btw, how did it happen that svn -> git move caused so much dispersion in
branch names? (tagging fortunately is more or less consistent, thanks to Dirk
most likely).
--
regards
MM
signature.asc
Description: This is a digitally signed message part.
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Release Team BoF at desktop summit
Hi, I'd like to organise a BoF at the desktop summit, as I think we have quite some stuff to talk about, for example: - tarball layout - release process and sustainability - communication inside the team, and outside of it - release schedule in the future - ... And more. In order to get a room and timeslot, I'd need a co-host, basically one of your names to put next to mine, so there's at least somebody in case I don't make it. Whose name can I put down? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On 06/21/2011 06:41 AM, Will Stephenson wrote: >>> So you want the fine grained tarballs, if I understand correctly ? >> Just looking at how the openSUSE buildservice is set up, they seem to >> use fine-grained tarballs as well, although I don't know how closely >> those match to the breakdown you are using. > > We're using them, and the consensus among the team so far is that they allow > faster builds (broader dependency tree instead of deeper) and isolate failures > better. These are the kde.org tarballs; is anyone using their own?? Fwiw, in fedora, we hacked the 4.6.80 kde.org tarballs and build-process to be as-close-to-monolithic as possible. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: RFC: Release Management Going Forward
On Monday 20 Jun 2011 23:02:56 todd rme wrote: > On Mon, Jun 20, 2011 at 10:57 PM, Alexander Neundorf wrote: > > On Monday 20 June 2011, Manuel Tortosa wrote: > >> El Monday, 20 of June de 2011, a les 22:39:40, Alexander Neundorf va > > > > escriure: > >> > Or, in other words, I do not yet have any feedback from packagers, > >> > except the early feedback from Sune in Randa, which is incorporated > >> > now, but no fresh feedback yet. > >> > >> Well in our case in Chakra we switched our buildsystem already for match > >> the new separated tarballs.as in fact. our start was KDEMod, a modular > >> KDE set of packages, so the new way is the natural way for us, even > >> more monolithic tarballs makes hard simple things like get the kate > >> perl bindings compiling only each tarball once. > > > > So you want the fine grained tarballs, if I understand correctly ? > > > > Alex > > Just looking at how the openSUSE buildservice is set up, they seem to > use fine-grained tarballs as well, although I don't know how closely > those match to the breakdown you are using. We're using them, and the consensus among the team so far is that they allow faster builds (broader dependency tree instead of deeper) and isolate failures better. These are the kde.org tarballs; is anyone using their own?? Will -- Will Stephenson, openSUSE Team SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
