[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-release-team
Subject: Re: git workflow draft
From: Jeremy Whiting <jpwhiting () kde ! org>
Date: 2011-08-31 15:38:10
Message-ID: CADWV2K7oZRKT4r5adJ7jCuR+B2TA1B8z30_oYBKHA=fXjU0pWQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I forgot to mention some details about my proposal. See below.
On Wed, Aug 31, 2011 at 9:07 AM, Jeremy Whiting <jpwhiting@kde.org> wrote:
> Ok it seems most people with a preference prefer KDE/X.Y over X.Y and for
> valid reasons
> 1) Other non-kde blessed branches can have obvious names.
> 2) Kdelibs, base, etc. are already KDE/X.Y
> 3) More modules are already KDE/X.Y than X.Y so less to fix when enforcin=
g
> consistency. (after looking at which repos would need to change, I'm not =
so
> sure about this one...)
>
>
Part of the problem with some repositories using X.Y branch naming and
others using KDE/X.Y is that scripts and people that work with our
repositories need to know which ones use which scheme.
My proposal to rename the branches is this. I (or someone else with access
to each repository) would checkout X.Y branch as KDE/X.Y then push it back
to the repository. Then the old X.Y branches on the repository would be
removed. This makes all the branches that are part of KDE SC follow the
consistent KDE/X.Y naming. Any existing clones with tracking branches to
X.Y named branches would then not be updated unfortunately. Which is the
reason for the announcement, posting the decision on techbase, including
instructions for updating tracking branches and so on.
In most cases, anyone with a clone without tracking branches will need to d=
o
this:
git remote update
git remote prune origin (or whatever they named the remote)
In cases where tracking branches to X.Y branches are created, they will nee=
d
to be recreated to track KDE/X.Y instead.
I hope this clarifies my proposal a bit. Feel free to ask any questions.
Jeremy
Thus I propose we agree to use KDE/X.Y for official kde release branches
> going forward and after tagging tomorrow put a notice on relevant mailing
> lists and on techbase. Then one week later perform the required changes =
to
> existing repositories.
> 1 kdegraphics
> 2 kdeedu
> 3 kdeutils
> 4 kdepim
> 5 kdepim-runtime
> 6 kdeplasma-addons
> 7 kdepimlibs
>
> If I've missed any in the above list, please add them.
> best regards,
> Jeremy
>
>
> On Wed, Aug 31, 2011 at 5:00 AM, Sebastian K=FCgler <sebas@kde.org> wrote=
:
>
>> On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:
>> > >> Was this decided upon at some point? I got conflicting stories fro=
m
>> > >> sysadmin and other developers. Yesterday after migrating
>> > >> kdeaccessibility to git I was asked by a sysadmin to rename the X.Y
>> > >> branches to KDE/X.Y I think concensus and consistency are importan=
t
>> > >> here. Was there a decision that the official branches should be
>> named
>> > >> X.Y?
>> > >
>> > > My vote goes to "KDE/X.Y", it is clearer what it means.
>> >
>> > When the frameworks get split out into multiple repos, will they still
>> use
>> > branch names KDE/5.0? What will that mean? Or will we come up with
>> another
>> > scheme then?
>>
>> I think they should, here's my reasoning:
>>
>> The KDE part of the branch name means it's our "official" branch, i.e.
>> it's
>> done by KDE (not by individuals acting on their own), so basically our
>> official namespace. We use $name/feature elsewhere, and I think KDE/5.37
>> would
>> blend in nicely here. On top of that, it gives some continuity.
>>
>> Cheers,
>> --
>> sebas
>>
>> http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
>>
>
>
[Attachment #5 (text/html)]
I forgot to mention some details about my proposal. See below.<br><br><div \
class="gmail_quote">On Wed, Aug 31, 2011 at 9:07 AM, Jeremy Whiting <span \
dir="ltr"><<a href="mailto:jpwhiting@kde.org">jpwhiting@kde.org</a>></span> \
wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex;">Ok it seems most people with a preference prefer \
KDE/X.Y over X.Y and for valid reasons<br>1) Other non-kde blessed branches can have \
obvious names.<br> 2) Kdelibs, base, etc. are already KDE/X.Y<br>3) More modules are \
already KDE/X.Y than X.Y so less to fix when enforcing consistency. (after looking at \
which repos would need to change, I'm not so sure about this one...)<br>
<br></blockquote><div><br>Part of the problem with some repositories using X.Y branch \
naming and others using KDE/X.Y is that scripts and people that work with our \
repositories need to know which ones use which scheme.<br> <br>My proposal to rename \
the branches is this. I (or someone else with access to each repository) would \
checkout X.Y branch as KDE/X.Y then push it back to the repository. Then the old X.Y \
branches on the repository would be removed. This makes all the branches that are \
part of KDE SC follow the consistent KDE/X.Y naming. Any existing clones with \
tracking branches to X.Y named branches would then not be updated unfortunately. \
Which is the reason for the announcement, posting the decision on techbase, including \
instructions for updating tracking branches and so on.<br> <br>In most cases, anyone \
with a clone without tracking branches will need to do this:<br>git remote \
update<br>git remote prune origin (or whatever they named the remote)<br><br>In cases \
where tracking branches to X.Y branches are created, they will need to be recreated \
to track KDE/X.Y instead.<br> <br>I hope this clarifies my proposal a bit. Feel free \
to ask any questions.<br><br>Jeremy<br><br></div><blockquote class="gmail_quote" \
style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); \
padding-left: 1ex;"> Thus I propose we agree to use KDE/X.Y for official kde release \
branches going forward and after tagging tomorrow put a notice on relevant mailing \
lists and on techbase. Then one week later perform the required changes to existing \
repositories.<br>
1 kdegraphics<br>2 kdeedu<br>3 kdeutils<br>4 kdepim<br>5 kdepim-runtime<br>6 \
kdeplasma-addons<br>7 kdepimlibs<br><br>If I've missed any in the above list, \
please add them. </blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt \
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <br>best \
regards,<br><font color="#888888">Jeremy</font><div><div></div><div \
class="h5"><br><br><div class="gmail_quote"> On Wed, Aug 31, 2011 at 5:00 AM, \
Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org" \
target="_blank">sebas@kde.org</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">
<div>On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:<br>
> >> Was this decided upon at some point? I got conflicting stories \
from<br> > >> sysadmin and other developers. Yesterday after migrating<br>
> >> kdeaccessibility to git I was asked by a sysadmin to rename the X.Y<br>
> >> branches to KDE/X.Y I think concensus and consistency are \
important<br> > >> here. Was there a decision that the official branches \
should be named<br> > >> X.Y?<br>
> ><br>
> > My vote goes to "KDE/X.Y", it is clearer what it means.<br>
><br>
> When the frameworks get split out into multiple repos, will they still use<br>
> branch names KDE/5.0? What will that mean? Or will we come up with another<br>
> scheme then?<br>
<br>
</div>I think they should, here's my reasoning:<br>
<br>
The KDE part of the branch name means it's our "official" branch, i.e. \
it's<br> done by KDE (not by individuals acting on their own), so basically \
our<br> official namespace. We use $name/feature elsewhere, and I think KDE/5.37 \
would<br> blend in nicely here. On top of that, it gives some continuity.<br>
<br>
Cheers,<br>
<font color="#888888">--<br>
sebas<br>
<br>
<a href="http://www.kde.org" target="_blank">http://www.kde.org</a> | <a \
href="http://vizZzion.org" target="_blank">http://vizZzion.org</a> | GPG Key ID: 9119 \
0EF9<br> </font></blockquote></div><br>
</div></div></blockquote></div><br>
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic